--- title: 'Advanced File Upload Attacks: Bypass Techniques and Secure Defenses' description: 'A comprehensive developer guide on advanced file upload vulnerabilities, including MIME bypass, polyglot images, Zip Slip, SVG XSS, PDF SSRF, and secure Laravel implementations.' faq: - { question: 'Why is MIME-type verification by the client insecure?', answer: "Client-side MIME-type checks and the HTTP Content-Type header are fully controlled by the client. Attackers can intercept the upload request using an intercepting proxy (like Burp Suite) and modify the header (e.g., changing 'application/x-php' to 'image/png') to bypass simple backend filters." } - { question: 'What is a polyglot image file, and how does it execute code?', answer: 'A polyglot image is a valid image file (possessing correct magic bytes and structures) that also contains valid code (like PHP script blocks) in its metadata or comments. If the server stores it in the web root with a .php extension or processes it via a vulnerable parser, the code executes.' } - { question: 'How can I prevent XSS from uploaded SVG files?', answer: "SVG files are XML documents and can contain embedded JavaScript. To prevent XSS, you should either sanitize the SVG (stripping scripts and event handlers), convert the SVG to a raster format (like PNG/JPEG) upon upload, or serve SVGs with the 'Content-Disposition: attachment' header to prevent browser execution." } published: '2026-07-09' --- # Advanced File Upload Attacks: Bypass Techniques and Secure Defenses File upload functionality is a standard feature in modern web applications. However, it is also one of the most critical attack vectors. If not secured correctly, it can lead to Remote Code Execution (RCE), Local File Disclosure (LFD), Server-Side Request Forgery (SSRF), and Cross-Site Scripting (XSS). This guide explores advanced file upload bypass techniques and details how to implement robust backend mitigations in PHP and Laravel. --- ## 1. MIME-Type Check Bypass ### The Vulnerability Web applications often check the `Content-Type` header sent by the client's browser to determine if a file is safe. For example, if you upload an image, the browser automatically sends: ```http Content-Type: image/png ``` If the application's backend only validates this header, it creates a severe security loophole. ### The Attack An attacker intercepts the upload request using a proxy tool like Burp Suite. They upload a malicious PHP web shell (`shell.php`) but modify the `Content-Type` header: ```http POST /upload HTTP/1.1 Host: vulnerable-app.com Content-Disposition: form-data; name="file"; filename="shell.php" Content-Type: image/png ``` Since the backend reads the modified header and believes the file is a safe PNG, it allows the upload. Once stored in a web-accessible directory, the attacker accesses `http://vulnerable-app.com/uploads/shell.php?cmd=id` to execute operating system commands. --- ## 2. Magic Bytes & Signature Manipulation ### The Vulnerability To combat basic MIME-type bypasses, developers often implement signature analysis. Every file format has a unique set of initial bytes, known as "magic bytes" or file signatures. For example: - **GIF**: `GIF89a` (`47 49 46 38 39 61`) - **PNG**: `\x89PNG\r\n\x1a\n` (`89 50 4E 47 0D 0A 1A 0A`) - **JPEG**: `\xFF\xD8\xFF` (`FF D8 FF`) If the server checks only these signature bytes at the beginning of the file, it remains vulnerable. ### The Attack An attacker prepends the valid file signature to their malicious code. For instance, creating a text file starting with `GIF89a;` followed by PHP code: ```http POST /upload HTTP/1.1 Host: vulnerable-app.com Content-Disposition: form-data; name="file"; filename="shell.gif.php" Content-Type: image/gif GIF89a; ``` When the backend reads the first few bytes, it detects the `GIF89a` signature and validates the file as an image. If the file is saved with a `.php` extension, the web server executes the payload. --- ## 3. EXIF Metadata Injections & Polyglot Files ### The Vulnerability A polyglot file is a file that is valid under multiple formats (e.g., both a valid image and a valid script). Advanced upload validators use deep parser inspection (like GD Graphics Library or ImageMagick) to read the image structure. However, image formats allow text comments or metadata structures (like EXIF tags in JPEG, or text chunks in PNG). ### The Attack Using tools like `exiftool`, attackers can inject a PHP payload into an image comment or metadata field without corrupting the image structure: ```bash exiftool -Comment="" exploit.jpg ``` If the backend only checks if the image is valid (e.g., using `getimagesize()` in PHP) and saves the file with a `.php` extension (or relies on a double extension/null byte bypass), the PHP parser will execute the code inside the metadata. > [!WARNING] > **Surviving Resizing & GD Re-encoding**: Simply running the image through a resizing library does not guarantee security. Attackers have developed "GD-proof" polyglots (specifically for PNG and JPEG) where the payload is placed in parts of the image data (such as the PLTE chunk or quantization tables) designed to survive compression and resizing algorithms. --- ## 4. Filename Path Traversal ### The Vulnerability During file uploads, the browser sends a `Content-Disposition` header containing the original filename. If the backend trusts this filename and concatenates it directly to the upload directory path, path traversal occurs. ### The Attack An attacker modifies the `filename` parameter to include traversal sequences (`../`): ```http POST /upload HTTP/1.1 Host: vulnerable-app.com Content-Disposition: form-data; name="file"; filename="../../../../var/www/html/shell.php" Content-Type: image/png ``` If the upload directory is `/var/www/html/storage/uploads/` and the application resolves the path dynamically, the file will be written to `/var/www/html/shell.php` instead of the restricted uploads folder. This allows the attacker to execute the shell directly from the web root or overwrite critical configurations. --- ## 5. Zip Slip (Path Traversal inside Archives) ### The Vulnerability When web applications accept compressed archives (e.g., `.zip` or `.tar`), the backend must unpack them. If the decompression routine does not validate the names of the files inside the archive, it is vulnerable to the "Zip Slip" exploit. ### The Attack The attacker creates a malicious archive where a file's name contains directory traversal sequences. When extracted, the file escapes the target directory: ```text Malicious Archive: └── ../../../../var/www/html/shell.php ``` If the backend uses standard extraction libraries without canonicalizing and checking the output path of each entry, the shell is written directly to the web root. --- ## 6. Client-Side XSS via SVG Uploads ### The Vulnerability SVG (Scalable Vector Graphics) is an XML-based vector image format. Because SVGs are XML documents, they can contain embedded scripts (` ``` When a user visits the direct link to the SVG, the embedded JavaScript executes in the context of the application's domain, allowing session hijacking, credential theft, or defacement. --- ## 7. SSRF & LFD via PDF Processing ### The Vulnerability Websites often process uploaded PDF files to generate previews/thumbnails or parse content. Tools like Ghostscript, `pdftoppm`, or PDF-to-HTML converters are commonly used. Many of these tools have a history of critical vulnerabilities (such as Ghostscript execution flaws). ### The Attack 1. **Local File Disclosure (LFD)**: An attacker uploads a PDF containing references to local resources (like `/etc/passwd` or `C:\Windows\win.ini`). The parsing engine reads and embeds the contents of these files into the rendered preview. 2. **Server-Side Request Forgery (SSRF)**: An attacker injects internal URLs (e.g., `http://169.254.169.254/latest/meta-data/` or internal admin endpoints) into the PDF structure. When the PDF processor attempts to resolve external resources or render links, it accesses the restricted internal networks. --- ## 8. Deep-Defense Mitigation Code Example (PHP/Laravel) To secure file uploads, developers must implement a multi-layered defense strategy. Relying on simple file validation is not enough. ### Secure Upload Implementation in Laravel Below is a complete, production-ready implementation of a secure upload controller in Laravel. ```php hasFile('uploaded_file')) { return response()->json(['error' => 'No file uploaded.'], 400); } $file = $request->file('uploaded_file'); // 1. Enforce strict extension whitelist $extension = strtolower($file->getClientOriginalExtension()); $allowedExtensions = ['jpg', 'jpeg', 'png', 'gif', 'svg']; if (!in_array($extension, $allowedExtensions)) { return response()->json(['error' => 'Invalid file extension.'], 400); } // 2. Determine real MIME type dynamically using server-side inspection (fileinfo) $realMime = $file->getMimeType(); $mimeToExtensionMap = [ 'image/jpeg' => ['jpg', 'jpeg'], 'image/png' => ['png'], 'image/gif' => ['gif'], 'image/svg+xml' => ['svg'], ]; if (!isset($mimeToExtensionMap[$realMime]) || !in_array($extension, $mimeToExtensionMap[$realMime])) { return response()->json(['error' => 'MIME type mismatch.'], 400); } // 3. Generate a non-predictable UUID filename to prevent path traversal and metadata leaks $uuid = Str::uuid()->toString(); $secureFilename = "{$uuid}.{$extension}"; // 4. Handle SVG Files separately (Sanitize to prevent XSS and XXE) if ($realMime === 'image/svg+xml') { try { $sanitizedSvg = $this->sanitizeSvg($file->getRealPath()); // Store on an isolated bucket/disk (e.g. AWS S3) outside the public root directory Storage::disk('s3')->put("uploads/{$secureFilename}", $sanitizedSvg, [ 'visibility' => 'private', 'ContentType' => 'image/svg+xml', 'ContentDisposition' => 'attachment; filename="' . $secureFilename . '"' // Force download or restrict direct script execution ]); } catch (\Exception $e) { return response()->json(['error' => 'SVG sanitization failed.'], 400); } } else { // 5. Re-encode raster images (JPEG/PNG/GIF) to strip EXIF data and destroy polyglots try { // Initialize Intervention Image (uses GD or ImageMagick) $img = Image::make($file->getRealPath()); // Perform a resize or re-encode to completely rebuild the pixel structure // This strips out all EXIF, metadata chunks, and breaks embedded PHP payloads. $stream = $img->stream($extension, 85); // 85% quality reconstruction // Store on a secure private disk Storage::disk('s3')->put("uploads/{$secureFilename}", $stream->__toString(), [ 'visibility' => 'private', 'ContentType' => $realMime, ]); } catch (\Exception $e) { return response()->json(['error' => 'Image processing failed.'], 500); } } return response()->json([ 'message' => 'File uploaded securely.', 'file_id' => $uuid, 'filename' => $secureFilename ], 200); } /** * Sanitizes SVG content by stripping script elements and inline events. */ private function sanitizeSvg(string $filePath): string { $xml = file_get_contents($filePath); if ($xml === false) { throw new \Exception('Unable to read SVG file.'); } $dom = new \DOMDocument(); // Disable external entity resolution (XXE prevention) libxml_use_internal_errors(true); libxml_disable_entity_loader(true); if (!$dom->loadXML($xml, LIBXML_NONET | LIBXML_NOENT | LIBXML_DTDLOAD)) { libxml_clear_errors(); throw new \Exception('Invalid XML structure.'); } // 1. Remove all