File upload vulnerabilities arise when an application accepts uploaded files without adequately validating their type, content, and storage location. The highest-impact case is uploading a server-executable file, a web shell, into a directory the server will run, giving remote code execution. Weaker validation also enables stored cross-site scripting, path traversal, and denial of service. The root causes are trusting the client-supplied filename or content type and storing uploads where they can be executed.
What file upload vulnerabilities are
An upload feature has to answer three questions safely: what is this file, where do I store it, and can it ever be executed. Vulnerabilities appear when any of those is handled with client-supplied trust.
The worst outcome is remote code execution: an attacker uploads a script, for example a PHP, JSP, or ASPX file, into a location under the web root, then requests it so the server executes it. Lesser but still serious outcomes include stored cross-site scripting from an uploaded HTML or SVG file, path traversal that overwrites files elsewhere, and resource exhaustion from oversized or decompression-bomb files.
The abuse and bypass tricks
Testers try to place an executable file past the app's checks. Shown for defensive context:
- Weak extension checks: try
shell.php, then bypasses such asshell.php.jpg,shell.pHp, or alternate executable extensions like.phtml,.php5,.aspx. - Content-type spoofing: send a script but set the
Content-Typeheader toimage/png. - Magic-byte prefixing: prepend real image header bytes so a content sniff passes, while the file still executes.
- Config file uploads: a crafted
.htaccesscan make the server treat new extensions as executable. - Reach and run: once uploaded, browse to the file's URL to trigger execution.
Because a single successful upload can mean full compromise, upload handling is scrutinized closely during web application security testing.
How to defend
Layer the controls so no single bypass wins:
- Validate type by content, not by name: check the actual file with a trusted library, and allowlist expected types rather than blocklisting bad ones.
- Store uploads outside the web root or in object storage, and serve them through a handler that never executes them.
- Rename files to random identifiers and drop the user-supplied name and extension so path and execution tricks fail.
- Disable script execution in the upload directory at the server level as a backstop.
- Enforce size and rate limits, and scan content where appropriate.
The single most effective control is ensuring uploaded files can never be executed by the server.
References
- [1]OWASP: File Upload Cheat Sheet(OWASP)
- [2]PortSwigger: File upload vulnerabilities(PortSwigger)
- [3]MITRE ATT&CK: Server Software Component: Web Shell (T1505.003)(MITRE)