File Upload Vulnerabilities: Tricks, Attacks, and How to Harden Your Uploads

Ever tried uploading a shell.php.jpg and wondered why it got blocked? It turns out the real tricks are subtler than you think. This article…

Very Lazy Tech 👾

~9 min read · March 12, 2026 (Updated: March 12, 2026) · Free: No

Ever tried uploading a shell.php.jpg and wondered why it got blocked? It turns out the real tricks are subtler than you think. This article unpacks common file-upload flaws (extension bypasses, MIME/magic spoofing, storage misconfig, etc.), shows examples of how attackers slip past naïve filters, and gives you concrete code snippets and fixes (PHP/Node.js) to lock things down.

For free practical guide: https://www.verylazytech.com/file-upload-vulnerabilities

TL;DR: File upload forms are a back-door to RCE or DoS if handled poorly. Attackers leverage tricks like double extensions (e.g. image.jpg.php), null-byte padding, or spoofed MIME types to sneak malicious files onto your server. Once in, those files can execute commands (think web shell) or trigger other bugs (XSS, SSRF, path traversal, etc.). Defenses include strict allow-lists (never just block bad exts), server-side MIME/magic-byte checks, sanitizing/renaming filenames, and safe storage (outside webroot, no script execution). Check out the table below for a quick overview of attack vectors vs mitigations, the flowchart for a secure upload process, and the code snippets for PHP/Node.js examples.

Why File Uploads Are Risky

By design, file uploads let users put arbitrary data on your server. If attackers slip in a script (e.g. a PHP shell), they might achieve Remote Code Execution (RCE) or full system takeover. Even without code, they can cause Denial of Service by filling disk space, or Defacement by overwriting pages. Intigriti notes file uploads are "common" and even part of OWASP's Top-10 (Insecure Design). In short: never trust client-side checks. Browsers and users control headers and filenames, so server-side validation is mandatory.

Attack example: In a naive PHP image site, an attacker uploads evil.php renamed to evil.png. The site stores it and serves it. Hitting example.com/uploads/evil.php runs the code. A sample payload could be <?php echo file_get_contents('/etc/passwd'); ?>.

Extension & Filename Bypass Tricks

A common defense is whitelisting extensions (e.g. only .jpg/.png). But attackers bypass this with tricks:

Double extensions: Name files like image.jpg.php or shell.png.Php5. Some filters just check for ".jpg" and miss the trailing ".php".
Null bytes / junk: Appending a null character or random text can fool poor filters. E.g. file.php%00.png or file.php.jpg with ASCII junk in between.
Case changes: PHP on Linux is case-sensitive, but Windows isn't. Try file.PHP or mixed-case (.pHp).
NTFS ADS trick (Windows): On NTFS, file.asp::$DATA.jpg creates a hidden file.asp stream on disk. This can later be crafted into a webshell.
Reserved names (Windows): Filenames like CON.jpg or NUL.png might crash or bypass scripts on some setups.

In short, OWASP warns that blind extension checks are dangerous — validate after decoding and be aware of edge cases. A safer approach is to extract the extension and compare against an allow-list after any nulls or encodings are removed:

// PHP example: naive extension check
$allowed = ['jpg','png','gif'];
$ext = strtolower(pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION));
if (!in_array($ext, $allowed)) {
    die("Invalid file extension");
}
move_uploaded_file($_FILES['file']['tmp_name'], "/uploads/".$_FILES['file']['name']);

In the above, shell.php.jpg would pass. Instead, strip null bytes and re-check:

// PHP: secure extension check + MIME sniffing
$filename = $_FILES['file']['name'];
// Remove null bytes
$filename = preg_replace('/\\0|\\r|\\n/', '', $filename);
$ext = strtolower(pathinfo($filename, PATHINFO_EXTENSION));
$allowed = ['jpg','png','gif'];
if (!in_array($ext, $allowed)) {
    die("Invalid extension");
}
// Verify MIME type via fileinfo (server-side sniffing)
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime = finfo_file($finfo, $_FILES['file']['tmp_name']);
if (!in_array($mime, ['image/jpeg','image/png','image/gif'])) {
    die("Invalid MIME type");
}
move_uploaded_file($_FILES['file']['tmp_name'], "/secure_uploads/".uniqid().".$ext");

Likewise in Node.js, use server-side checks (e.g. file-type library):

// Node.js (Express + Multer) example
const FileType = require('file-type');
const upload = multer({ dest: 'uploads/' }).single('file');
app.post('/upload', upload, async (req, res) => {
  const allowedExts = ['jpg','png','gif'];
  const ext = req.file.originalname.split('.').pop().toLowerCase();
  if (!allowedExts.includes(ext)) {
    return res.status(400).send('Extension not allowed');
  }
  // Check file signature
  const type = await FileType.fromFile(req.file.path);
  if (!type || !allowedExts.includes(type.ext)) {
    return res.status(400).send('Content mismatch');
  }
  // All good — move to safe location
  fs.renameSync(req.file.path, '/safe_uploads/'+req.file.filename+'.'+ext);
  res.send('File uploaded!');
});

This Node code strips the extension and then verifies the real file type by reading its header. It rejects files where .ext doesn't match the actual content type. This thwarts tricks like renaming a PHP file to .jpg.

Bypassing MIME and Magic-Number Checks

Some apps peek at the Content-Type header or file magic bytes (file signature) for extra security. But both can be gamed. For example:

Fake Content-Type: A client can set Content-Type: image/jpeg on a .php file. The server will trust it unless you re-check on the server side.
Magic bytes slip-ins: Prepend a real image header to a malicious file. E.g., add \x89PNG\r\n\x1a\n at the start of a .php webshell. A quick command:

printf '\x89PNG\r\n\x1a\n' > fake.png cat shell.php >> fake.png

Now fake.png starts with valid PNG bytes but is really a PHP file. A naive magic-byte check (file sniffing) sees "valid PNG".

Defense: Don't trust client headers. Server-side, use a library or OS facilities to inspect content. In PHP, finfo_file (as above) can do better than $_FILES['file']['type']. In Node, use packages like file-type or mime. Re-encoding images (e.g. resize or re-save through GD/ImageMagick) can wipe injected data. And remember OWASP's advice: file signature checks "should not be used on its own" – always combine with other checks.

Other Sneaky Upload Tricks

Beyond extensions and MIME, attackers have many tricks up their sleeve:

SVG and Script XSS: SVG images are XML and can contain <script> tags. If you allow .svg uploads and then display them, attackers can execute JS in users' browsers. Similarly, an HTML file renamed as an image could run script on the client. If your upload directory shares the same domain, this is dangerous. Best bet: ban script-capable formats (SVG/HTML) or serve uploads from a separate domain/subdomain with strict Content Security Policy.
Filename-based XSS: Even a normal filename can inject script if you're not careful. E.g. an attacker names their file <svg onload=alert(1)>. If your UI prints that filename unescaped, boom XSS. Always sanitize or ignore user-supplied filenames when generating HTML.
Path Traversal: If your code naively concatenates paths, filename=../../../etc/passwd might break out of the upload dir. OWASP and Intigriti both warn to sanitize paths. For example, use PHP's basename() or whitelist allowed characters. Better yet, generate your own filenames (UUIDs) and ignore the original name.
Windows Traps: On Windows servers, filenames like foo.. or foo::$DATA can create weird behaviors or hidden files. Also "CON", "NUL", "PRN" are reserved. OWASP's cheat sheet suggests randomizing filenames to avoid these issues.
SQL Injection: Storing filenames in a database can invite SQLi.

In essence, treat any user-supplied filename or content as untrusted input. Normalize or sanitize aggressively. For example, remove ../, special chars, very long names, non-printable chars, etc..

From Uploads to Full Blown Exploits

File-upload flaws often chain into bigger bugs. Some scenarios:

Remote Code Execution (RCE): The classic. Upload a web shell (PHP, JSP, ASP, etc.) and hit it via HTTP. The SentinelOne CVE analysis says unauthenticated attackers could "upload malicious files to execute arbitrary code remotely".
Local File Inclusion (LFI): If your app has an LFI bug (e.g. include($_GET['file'])), uploading a file gives attackers content to include. A malicious upload becomes a weapon.
Cross-Site Scripting (XSS): As noted, SVG or even image metadata with script can trigger XSS. OWASP notes DOM-based attacks or content-based XSS can arise from uploads.
Server-Side Request Forgery (SSRF): Some uploaders let users supply a URL to fetch the file. An attacker could point this at internal resources (http://localhost/admin). Restrict or remove any "remote upload" features, or validate destinations.
SSL/XXE in Documents: Even PDFs or Word docs can hide scripts or XML entities. An attacker can craft a PDF to bypass CORS or do XXE on servers that auto-process uploads.
Antivirus Evasion: Clever attackers might try to embed scripts in an "innocent-looking" file, hoping AV scans miss it. Always assume AV can catch some known payloads, but not 100%. In testing, people even upload the harmless EICAR test file to see if AV stops them.

Put simply: once you let an attacker drop a file on your system, the game is over unless you've compartmentalized and sanitized at every step.

Hardening File Uploads (Defense-in-Depth)

Protecting uploads means multiple layers of checks and controls. Key practices include:

Whitelist Extensions, Don't Rely on Blocking: Use an allow-list of only the file types your app needs. For example, an image forum might only allow jpg/png/gif, nothing else. OWASP warns that blocklists are weak; allowlists are safer. Check extensions after normalizing the filename (strip \0, URL-encodings, etc.).
Validate Content on Server: Don't trust Content-Type. Re-verify on the server, e.g. with PHP's finfo or a library in Node.js. Checking the magic bytes of the file (signature) is also recommended, but do not use it alone.
Sanitize or Rename Filenames: Never use the original filename as-is. Either generate a random name (UUID) or at least strip dangerous characters and disallow things like .. or :. Reject or remap reserved names. Limiting filename length (e.g. max 100 chars) avoids overflow issues.
Store Safely: Place uploaded files outside the webroot, or on a separate domain/host. If they must live in the webroot, set permissions so they are not executable. For example, in Apache you can turn off PHP execution in the upload directory:

<Directory "/var/www/html/uploads">
   php_admin_flag engine off
   <FilesMatch "\.(php|phar|phtml|asp|aspx)$">
     Require all denied
   </FilesMatch>
 </Directory>

(This forces uploaded scripts to be downloaded, not run.)
Use Least Privilege: The web server user should only have write access to the upload folder — not to system files or config. Follow OWASP: uploaded files should only be writable by the app, and only readable by users who need them. If possible, segregate upload handling to a non-privileged process or container.
Scan for Malware: Integrate antivirus/malware scanning (e.g. ClamAV, VirusTotal API) on uploads. At minimum, filter out known-bad signatures or execute uploads in a sandbox. Beware: public scanners can leak data, so quarantine files first.
Limit Size and Rate: Enforce file-size limits on the server (not just via HTML forms) to prevent DoS. Also limit request rate or number of files per user to curb abuse.
Require Auth/Validation: Only authenticated users (or trusted roles) should be allowed to upload, unless absolutely necessary. Log upload activity and review failures. Monitor the upload directory for suspicious new files or repeated attempts.
Defense in Depth: Finally, treat uploaded content as untrusted data everywhere. If you display images, serve them from a different domain/subdomain to leverage same-origin policy. If you must convert or parse files (PDFs, docs), do so using updated libraries in a locked-down environment.

Most of these recommendations come straight from OWASP's File Upload Cheat Sheet and real-world CVE write-ups. In practice, use several at once — whitelisting and server-side MIME checks and safe storage, etc. Don't rely on just one defense.

Conclusion & Takeaways

File-upload vulnerabilities are tricky but preventable if you never trust the client. As OWASP and experts emphasize: use an allow-list, validate on the server, sanitize everything, and lock down execution. The main points:

Always perform server-side checks. Extension checks alone are not enough — re-check MIME types and file signatures with trusted libs.
Block known bad patterns. Normalize filenames: strip nulls/encodings, reject ../, limit length, remove hidden chars.
Harden storage. Save uploads outside the webroot or on a separate service; disable script execution in the upload folder.
Principle of least privilege. The upload directory/user should only have write access, never execute. If scripts must process the file later, scan it first.
Monitor & scan. Log upload events and use antivirus or content scanners (e.g. ClamAV/VirusTotal) as part of your pipeline.
Educate users. Show them allowed file types and size limits; this reduces accidental misuse.

Staying secure is a cat-and-mouse game: attackers will keep inventing new tricks. But using a multi-layered defense (input validation, content inspection, safe config) goes a long way toward making your upload feature bulletproof.