How We Audited a High-Traffic WooCommerce Enterprise Stack on DigitalOcean and Mitigated Remote Code Execution (RCE) via insecure file uploads

Initial Stack Assessment and Threat Modeling

Our engagement began with a deep dive into the existing infrastructure supporting a high-traffic WooCommerce enterprise deployment on DigitalOcean. The stack comprised several key components: a cluster of DigitalOcean Droplets running Ubuntu LTS, Nginx as the primary web server and reverse proxy, PHP-FPM for application execution, MySQL for database persistence, Redis for caching, and a custom PHP-based plugin handling product image uploads and processing. The primary concern was the potential for Remote Code Execution (RCE) stemming from vulnerabilities within the application layer, particularly the custom upload plugin.

A rapid threat model was constructed, focusing on the attack vectors most relevant to a web application of this nature. Key threats identified included:

• Insecure file upload handling leading to arbitrary file execution.
• SQL Injection vulnerabilities in custom code or third-party plugins.
• Cross-Site Scripting (XSS) vulnerabilities.
• Server-side request forgery (SSRF).
• Exploitation of outdated software versions (OS, PHP, Nginx, MySQL).
• Weak authentication and authorization mechanisms.

The custom image upload plugin immediately flagged as a high-risk area. Its function involved accepting user-uploaded image files, performing some basic validation (file type, size), resizing them using GD or Imagick, and storing them on the filesystem. The critical question was: how was the uploaded file’s *actual* content and *potential execution* handled after the initial validation?

Deep Dive into the Insecure File Upload Mechanism

We requested access to the source code of the custom WooCommerce plugin. The relevant upload handler, simplified for illustration, revealed a critical flaw:

The plugin accepted files, performed a MIME type check and a file extension check, and then moved the uploaded file to a designated `uploads/` directory. Crucially, it did not sufficiently sanitize the filename or prevent the upload of files with executable extensions, nor did it enforce strict content-type validation beyond what the browser might send. Furthermore, the `uploads/` directory was configured with write permissions for the web server user and was accessible via a direct URL, bypassing any application-level security checks for execution.

// Simplified and illustrative example of the vulnerable code
$target_dir = "/var/www/html/wp-content/uploads/";
$uploaded_file = $_FILES["imageFile"];
$file_name = basename($uploaded_file["name"]);
$target_file = $target_dir . $file_name;
$file_type = mime_content_type($uploaded_file["tmp_name"]); // Basic MIME check

// Vulnerable checks:
// 1. Allows .php, .phtml, .phar extensions if not explicitly blocked.
// 2. Does not sanitize filename for malicious characters.
// 3. Does not verify actual content against declared MIME type rigorously.

if (move_uploaded_file($uploaded_file["tmp_name"], $target_file)) {
    // File moved successfully.
    // The file is now accessible via http://yourdomain.com/wp-content/uploads/malicious.php
    // and could be executed by the web server.
    echo "The file ". htmlspecialchars($file_name). " has been uploaded.";
} else {
    echo "Sorry, there was an error uploading your file.";
}

An attacker could craft a malicious PHP script (e.g., a webshell) and upload it by naming it `shell.php` or `backdoor.phtml`. If the server’s PHP configuration allowed execution of files in the `uploads/` directory (which is common for web servers serving static content), this would grant the attacker direct RCE capabilities.

Diagnostic Steps and Evidence Gathering

To confirm the vulnerability and understand its exploitability, we performed the following diagnostic steps:

• Manual Upload Test: We attempted to upload a file named `test.php` containing `<?php phpinfo(); ?>` through the plugin’s interface. The upload succeeded, and we were able to access `http://yourdomain.com/wp-content/uploads/test.php` in a browser, which displayed the PHP information page. This confirmed direct execution.
• Server-Side Analysis: We logged into a staging environment mirroring production and examined the `uploads/` directory permissions and Nginx configuration. We verified that the web server user (e.g., `www-data`) had write permissions and that Nginx was configured to serve files from this directory without any specific restrictions on executable file types.
• Nginx Configuration Review: We inspected the Nginx site configuration for the WooCommerce application. The relevant `location` block for serving static assets typically looks something like this, and in this case, it lacked specific directives to disallow PHP execution in the uploads directory:

location /wp-content/uploads/ {
    try_files $uri $uri/ /index.php?$args;
    expires 30d;
    access_log off;
    add_header Cache-Control "public";
}

The `try_files $uri $uri/ /index.php?$args;` directive is a common WordPress pattern, but when combined with an `uploads/` directory that can contain executable scripts, it becomes a vector. If Nginx cannot find a file matching the URI, it passes the request to PHP-FPM, which would then execute a script like `shell.php` if it existed.

Mitigation Strategy: Secure File Uploads

The primary mitigation involved a multi-layered approach to secure the file upload process:

• Server-Side Validation Enhancement: The most critical fix was to enhance the server-side validation within the plugin. This included:
  • Strict File Extension Whitelisting: Only allow known safe image extensions (e.g., `jpg`, `jpeg`, `png`, `gif`, `webp`).
  • MIME Type Verification: Use `finfo_file` (PHP’s fileinfo extension) to get the MIME type based on file content, not just the extension or `$_FILES[‘type’]`. Compare this against a whitelist of acceptable image MIME types.
  • Filename Sanitization: Remove or replace any characters that could be interpreted as code or path traversal sequences.
  • Content Inspection: For critical uploads, consider using libraries like ImageMagick or GD to *re-process* the image. This often strips out embedded metadata or executable code.
• Nginx Configuration Hardening: Modify the Nginx configuration to explicitly deny execution of PHP files within the uploads directory. This acts as a crucial defense-in-depth measure, even if the application-level validation were to fail.
• Filesystem Permissions: Ensure the `uploads/` directory is not directly executable by the web server. If possible, store uploads outside the webroot and serve them via a controlled script. If within the webroot, restrict execute permissions.
• Content Security Policy (CSP): Implement a robust CSP header to prevent the browser from executing scripts from untrusted sources, including the uploads directory.

Implementing Nginx Configuration Hardening

The Nginx configuration was updated to prevent PHP execution in the uploads directory. This is achieved by adding a specific `location` block that overrides the general one and denies requests for PHP files.

location ~* ^/wp-content/uploads/.*\.(php|phtml|php3|php4|php5|php7|phps|inc|cgi|pl|py|sh)$ {
    deny all;
    return 403;
}

location /wp-content/uploads/ {
    try_files $uri $uri/ /index.php?$args;
    expires 30d;
    access_log off;
    add_header Cache-Control "public";
}

Explanation:

• The first `location` block uses a regular expression (`~*`) to match any request that ends with common PHP or script extensions within the `/wp-content/uploads/` path. `deny all;` immediately blocks these requests, returning a 403 Forbidden error.
• The second `location` block, which is more general, then handles legitimate file requests (images, CSS, JS, etc.) from the uploads directory.

After applying this change, we re-tested the upload of `test.php`. The request was now met with a 403 Forbidden error, confirming that Nginx was successfully preventing execution.

Refining the PHP Upload Handler

The PHP code was refactored to incorporate robust validation. Here’s an improved version:

// Improved and more secure upload handler
$target_dir = "/var/www/html/wp-content/uploads/";
$uploaded_file = $_FILES["imageFile"];

// Define allowed MIME types and extensions
$allowed_mime_types = [
    'image/jpeg',
    'image/png',
    'image/gif',
    'image/webp'
];
$allowed_extensions = ['jpg', 'jpeg', 'png', 'gif', 'webp'];

// 1. Check if file was uploaded without errors
if ($uploaded_file["error"] !== UPLOAD_ERR_OK) {
    // Handle specific upload errors
    error_log("File upload error: " . $uploaded_file["error"]);
    wp_send_json_error(['message' => 'File upload failed.']);
    exit;
}

// 2. Basic check for file size (adjust as needed)
if ($uploaded_file["size"] > 5 * 1024 * 1024) { // 5MB limit
    wp_send_json_error(['message' => 'File is too large.']);
    exit;
}

// 3. Get MIME type using fileinfo extension (more reliable)
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$file_mime_type = finfo_file($finfo, $uploaded_file["tmp_name"]);
finfo_close($finfo);

if (!in_array($file_mime_type, $allowed_mime_types)) {
    wp_send_json_error(['message' => 'Invalid file type.']);
    exit;
}

// 4. Get file extension and sanitize filename
$original_filename = basename($uploaded_file["name"]);
$file_extension = strtolower(pathinfo($original_filename, PATHINFO_EXTENSION));

if (!in_array($file_extension, $allowed_extensions)) {
    wp_send_json_error(['message' => 'Invalid file extension.']);
    exit;
}

// Sanitize filename: remove potentially harmful characters, ensure it's safe
$safe_filename = preg_replace("/[^a-zA-Z0-9._-]/i", "_", $original_filename);
$safe_filename = str_replace(['..', '/', '\\'], '_', $safe_filename); // Prevent path traversal

// Ensure filename doesn't start with a dot or contain malicious sequences
if (strpos($safe_filename, '.') === 0 || strpos($safe_filename, '..') !== false || strpos($safe_filename, '/') !== false || strpos($safe_filename, '\\') !== false) {
    wp_send_json_error(['message' => 'Invalid filename.']);
    exit;
}

// Prevent overwriting existing files by appending a timestamp or counter if needed
$final_filename = $safe_filename;
$counter = 1;
while (file_exists($target_dir . $final_filename)) {
    $final_filename = pathinfo($safe_filename, PATHINFO_FILENAME) . '_' . $counter . '.' . $file_extension;
    $counter++;
}

$target_file = $target_dir . $final_filename;

// 5. Move the file
if (move_uploaded_file($uploaded_file["tmp_name"], $target_file)) {
    // File moved successfully.
    // Log the successful upload, potentially store metadata in DB.
    // Consider using ImageMagick/GD to re-process the image here for extra safety.
    // Example:
    // $image = new Imagick($target_file);
    // $image->stripImage(); // Remove metadata
    // $image->writeImage($target_file);
    // $image->destroy();

    wp_send_json_success(['message' => 'The file ' . esc_html($final_filename) . ' has been uploaded.', 'filename' => $final_filename]);
} else {
    error_log("Failed to move uploaded file to: " . $target_file);
    wp_send_json_error(['message' => 'Sorry, there was an error moving your file.']);
}

This revised PHP code implements several critical security improvements:

• Error Handling: Explicit checks for upload errors.
• Size Limit: Basic size enforcement.
• MIME Type Verification: Uses `finfo_file` for content-based MIME type detection.
• Extension Whitelisting: Strict check against allowed image extensions.
• Filename Sanitization: Robust sanitization to prevent path traversal and malicious characters.
• Collision Handling: Prevents overwriting existing files.
• Defense-in-Depth: The commented-out ImageMagick section shows an optional but highly recommended step to re-process images, stripping metadata and ensuring they are valid image formats.

Further Security Hardening and Monitoring

Beyond the immediate RCE fix, we recommended and implemented several other security enhancements:

• Regular Software Updates: Ensured all Droplets, Nginx, PHP, MySQL, and WordPress core/plugins/themes were kept up-to-date. Automated security patching was configured where appropriate.
• Web Application Firewall (WAF): Deployed a WAF (e.g., ModSecurity with OWASP Core Rule Set, or a cloud-based WAF) to provide an additional layer of defense against common web attacks.
• File Integrity Monitoring (FIM): Implemented FIM tools (e.g., AIDE, OSSEC) to detect unauthorized modifications to critical system files and application code.
• Access Control: Reviewed and tightened SSH access, implemented key-based authentication, and restricted unnecessary ports. For DigitalOcean, this includes using VPC firewalls.
• Logging and Alerting: Centralized logs from Nginx, PHP-FPM, and system logs. Configured alerts for suspicious activity (e.g., repeated 403 errors on PHP files in uploads, unusual access patterns, critical system errors).
• PHP Configuration (`php.ini`): Ensured `php.ini` was configured securely, disabling dangerous functions (`disable_functions`), setting appropriate `upload_max_filesize` and `post_max_size`, and ensuring `open_basedir` was configured if possible to restrict file access.

Conclusion

This case study highlights a common yet critical vulnerability: insecure file uploads. By combining thorough code review, diagnostic testing, and a defense-in-depth strategy involving both application-level fixes and infrastructure hardening (Nginx configuration, filesystem permissions), we successfully mitigated the RCE risk. For high-traffic enterprise applications, continuous security auditing, robust validation, and proactive monitoring are not optional but essential components of a resilient architecture.