Cybersecurity glossary
What is Unrestricted File Upload?
Learn what unrestricted file upload (CWE-434) is, how missing type, size, and extension controls enable webshells and malware, and how allowlists stop dangerous uploads.
Definition
Unrestricted File Upload (CWE-434) is a vulnerability in which an application accepts files without adequate restrictions on type, size, extension, or content—allowing attackers to upload dangerous formats that the server or other users later process or execute.
Why unrestricted uploads are dangerous
When an application accepts “any file,” attackers choose the format that hurts you most: server scripts, HTML for stored XSS, or archives packed with traversal entries. Unrestricted File Upload—tracked as CWE-434—is the classic missing-control flaw behind countless webshell footholds.
It is a specific intake failure inside the wider file upload vulnerability space. Closely related abuses include malicious file upload, extension/path confusion, and multi-format polyglot files.
How CWE-434 is exploited
Map accepted inputs
Observe which extensions, MIME types, and sizes the endpoint silently accepts.
Craft a dangerous type
Prepare a script, HTML/SVG, executable, or archive the filters do not reject.
Defeat superficial checks
Spoof Content-Type, rename extensions, or embed payloads inside allowed wrappers.
Abuse stored content
Request the file for execution, XSS, malware delivery, or further processing bugs.
Controls attackers expect to be missing
No type allowlist
Anything uploads: .php, .aspx, .jsp, .html, .exe, or custom script extensions.
Extension-only filters
Blacklists miss variants; [path confusion](/glossary/path-confusion) and double extensions slip through.
No size caps
Huge bodies exhaust disk/bandwidth and enable [decompression bomb](/glossary/decompression-bomb) scenarios.
Trusted client metadata
Relying on browser Content-Type or original filename as security signals.
Prevention that works
| Control | Notes |
|---|---|
| Strict type allowlist | Permit only business-needed formats; verify magic bytes server-side |
| Reject dangerous families | Block scripts, HTML, SVG (if unused), and executables by policy |
| Enforce size limits | Cap request body, per-file size, and total storage per user |
| Normalize extensions | Map detected type to a canonical extension you choose |
| Decouple from execution | Never store uploads where the app server interprets code |
| Defense-in-depth scanning | Malware AV helps; still fix allowlisting and serving headers |
- Replace extension blacklists with an explicit allowlist of permitted formats.
- Validate file content (magic bytes / parsers) independently of the filename.
- Apply hard size and rate limits at the reverse proxy and application layers.
- Generate server-side filenames; never reuse user-controlled names or paths.
- Ensure uploaded objects cannot be executed by PHP, Node, IIS, or similar runtimes.
- Test bypasses: double extensions, case variants, null bytes, and spoofed MIME types.
- Review whether SVG/HTML uploads can create stored [XSS](/glossary/cross-site-scripting-xss).
- Document CWE-434 findings with clear evidence of accepted dangerous types.
The practical takeaway
Unrestricted file upload (CWE-434) means the gate was left open: no trustworthy limits on type, size, or extension. Close it with allowlists, content verification, and storage that cannot execute user bytes.
If your upload handler’s only defense is “block .php,” assume it is still unrestricted until proven otherwise.
Related security terms
File Upload Vulnerability
Broader category covering validation, storage, serving, and parser risks.
Malicious File Upload
Deliberately hostile payloads placed through upload features.
Path Confusion
Ambiguous path or extension handling that bypasses security checks.
Polyglot File
Multi-format files used to defeat naïve type filters.
Frequently asked questions
What does unrestricted file upload mean?
The server does not meaningfully limit what kinds of files—or how large—users can send, so dangerous types like scripts, executables, or HTML can be stored and later abused.
Is CWE-434 only about missing extension checks?
No. It covers inadequate control of dangerous types overall: extensions, MIME, magic bytes, size, and downstream execution of uploaded content.
How do attackers bypass weak allowlists?
Double extensions (.php.jpg), case tricks, alternate extensions (.phtml), null bytes, Content-Type spoofing, and [polyglot files](/glossary/polyglot-file) that pass image checks yet remain executable.
Why is size limiting part of this issue?
Unbounded uploads enable denial of service and amplify archive attacks such as a [zip bomb](/glossary/zip-bomb) or [decompression bomb](/glossary/decompression-bomb).
What is the primary fix?
Server-side allowlisting of permitted formats with content verification, plus storage and serving designs that never execute user files.
Can blocking .php alone be enough?
Rarely. Runtimes accept many script extensions, parsers have their own risks, and [path confusion](/glossary/path-confusion) can make blocked names still execute.
How is this different from a general file upload vulnerability?
Unrestricted upload focuses on missing intake controls (type/size/extension). The broader [file upload vulnerability](/glossary/file-upload-vulnerability) also includes storage layout, serving headers, and extract/parser flaws like [Zip Slip](/glossary/zip-slip).
References
Explore authoritative guidance and frameworks related to unrestricted file upload.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.