Module 7 · File Upload — Three Attacks in One 🔒

File upload is deceptively simple to describe and catastrophic when wrong. The developer’s mental model: “user uploads file, we store it.” The reality: “user supplies arbitrary bytes to a server context with multiple possible interpretations, and we must choose the right one at every stage.” Each stage has its own rules. Mistakes compound.

Why this happens

A file is an attack surface at three junctures: parsing, storage, and serving. Developers mostly think about the first (can I parse it without crashing?) and barely about the third (how will it be served back?). Storage is often naive. Each juncture has distinct failure modes.

Additionally, “file” is polymorphic. A single byte stream can be simultaneously a valid image and a valid HTML page (polyglot files). Browsers may sniff content type and ignore your Content-Type header. CDNs may re-interpret. Image processing libraries may have RCE vulns that execute when parsing maliciously-crafted images. The “file” you received isn’t just one thing.

How it goes wrong

1. Unsafe filename extension

User uploads shell.php. Server saves as uploads/shell.php. Web server serves PHP files from uploads/. Attacker gets RCE via web-accessible PHP. Still happens in 2026 on misconfigured Apache/Nginx.

2. Content-type spoof

User uploads shell.php with Content-Type: image/jpeg. Server trusts Content-Type and renames to .jpg. Attacker later finds the file served as JPEG but browser/Apache misidentifies via magic bytes, or server includes it via require().