Category:
Web ApplicationSummary:
How unrestricted file upload lets attackers plant a web shell or malicious file for code execution, and how to constrain uploads safely.Unrestricted file upload happens when an app accepts an uploaded file without validating its type, content, or storage location, letting an attacker drop a web shell — .php, .jsp, .aspx — into a directory the server will execute for command execution. It’s frequently chained from XSS via SVG or HTML uploads that carry script, and once a shell lands it’s a classic foothold alongside SQL injection for deeper access.
Common Techniques
- Double-extension & MIME spoofing —
shell.php.jpgor a forgedContent-Typeheader slips past naive checks. - Null-byte /
.phtmltricks — alternate executable extensions or legacy null-byte truncation bypass an extension filter. - Content-type bypass — client-supplied MIME type is trusted instead of the file’s actual content.
- Path traversal in filename —
../../in the filename writes outside the intended upload directory. - Polyglot / SVG-XSS files — a file valid as both an image and a script triggers execution in the browser.
Want to save time on reporting?
Let PentestPad generate, track, and export your reports - automatically.

Testing
Start with a benign marker file uploaded to a path you don’t expect to execute, to map behavior safely:
upload: test.php.jpg (Content-Type: image/jpeg)Check what extension and content checks actually run, then confirm whether the stored file lands somewhere web-reachable and executable — that combination is what turns a lax upload filter into RCE. Record the accepted file, its final path, and whether it executed in the pentest report.
Remediation
Allowlist extensions and validate actual file content (magic bytes, not just the claimed MIME type) — either check alone is bypassable. Store uploads outside the web root with randomly generated names, serve them only through a handler that never executes file content, and run uploaded files through malware scanning with a hard size limit.