What it is
File upload is one of the most varied attack surfaces in web applications because every layer between the user clicking 'attach' and the file being served back has its own failure modes. Client-side validation is bypassable by definition. Server-side validation by extension is bypassable by content-type spoofing. Storage in a web-served directory turns 'profile picture' into 'web shell.' SVGs are HTML in disguise. PDFs can contain JavaScript. Even legitimate images contain enough metadata to leak GPS coordinates of the user's bedroom. The bug is rarely in any one check — it's in the gap between checks.
How it happens
File-upload weaknesses appear when applications accept, store, or serve uploaded content without strict validation and isolation. The impact ranges from stored script execution to content spoofing or resource abuse.
What an attacker gets
Web shell upload graduates to remote code execution as the web server user — full host compromise from there. SVG-based XSS captures sessions of every user who views the malicious avatar. Storage exhaustion / DoS when no size cap is enforced. Hosting illegal content on your CDN brings legal liability you didn't sign up for. Path traversal can overwrite application code or config files. Image metadata (EXIF) leaks GPS, device info, software fingerprints — privacy and stalking concerns even when no execution happens.
// what fixvibe reports
What FixVibe reports
Runs in active scans of a domain you have verified you own, on Hobby and above. Each finding shows the affected URL or host, its severity and fix steps you can paste into your AI coding tool.
How to fix it
Validate by file content, not by extension or claimed MIME type. Read the magic bytes (the first few bytes that identify a file format) and verify they match what the user said the file is. For images, re-encode through a server-side processor (sharp, ImageMagick — patched, sandboxed) — this strips EXIF, normalizes the format, and discards weird embedded payloads. Store uploads outside the web root entirely, or in a dedicated storage bucket (S3, R2, GCS) with no execute permission. Serve uploaded files from a separate domain (`uploads.yourapp.com`, not `yourapp.com/uploads`) with a restrictive Content-Security-Policy preventing script execution; this contains SVG-XSS to a sandboxed origin. Generate non-guessable filenames server-side (UUIDs, never the user's filename). Limit file size aggressively at the HTTP layer (nginx `client_max_body_size`, framework body-size middleware). Reject SVG entirely unless your use case truly requires it; if it does, run uploads through DOMPurify with SVG mode. For ZIP/archive uploads, use a battle-tested extractor that resolves and verifies each entry path is within the target directory.