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

Initial Triage: Identifying the Attack Vector

Our engagement began with a critical alert: a high-traffic WordPress enterprise stack hosted on OVH was exhibiting anomalous behavior, strongly suggesting a compromise. The initial indicators pointed towards a potential Remote Code Execution (RCE) vulnerability, a severe threat that could allow an attacker full control over the server. The primary suspect for such a vulnerability in a WordPress context, especially one involving file manipulation, is often an insecure file upload mechanism.

The stack comprised several components: a cluster of WordPress instances, a shared MySQL database, Redis for caching, and Nginx as the web server, all running on OVH’s dedicated servers. The sheer volume of traffic meant that any exploit could propagate rapidly and cause significant damage.

Deep Dive into File Upload Functionality

Our first step was to meticulously audit the custom and third-party plugins responsible for handling file uploads. Many WordPress sites, particularly enterprise-level ones, rely on custom solutions or extended functionality from plugins for features like media management, document submission, or user-generated content. These are prime targets for RCE if not implemented with robust security controls.

We focused on identifying any plugins that allowed users to upload files without proper validation of file types, sizes, or content. A common RCE pattern involves uploading a script (e.g., a PHP shell) disguised as an innocuous file type (like an image). If the server then executes this script, the attacker gains RCE.

A specific plugin, let’s call it “Advanced Media Uploader,” was flagged for review. Its functionality allowed users to upload various document types, including PDFs, DOCX, and images, directly into the WordPress media library or custom directories. The audit revealed a critical flaw in its file type validation logic.

Exploiting the Vulnerability: Proof of Concept

The “Advanced Media Uploader” plugin, in its earlier versions, performed a rudimentary check based on the file extension provided in the HTTP request, rather than inspecting the actual MIME type or file content. This allowed an attacker to rename a PHP script to something like shell.jpg and upload it successfully.

To confirm this, we crafted a simple PHP webshell:

<?php
// Simple webshell for testing RCE
if(isset($_REQUEST['cmd'])){
    echo "<pre>";
    $cmd = ($_REQUEST['cmd']);
    system($cmd);
    echo "</pre>";
    die;
}
?>

We then renamed this file to shell.jpg and attempted to upload it via the “Advanced Media Uploader” interface. The plugin, failing to perform adequate server-side validation, accepted the file. The uploaded file was placed in a predictable directory, often within wp-content/uploads/, possibly with a timestamped subdirectory.

Once uploaded, we could directly access the shell via its URL. For instance, if the file was uploaded to /wp-content/uploads/2023/10/shell.jpg, we could execute commands by appending parameters to the URL:

https://your-wordpress-site.com/wp-content/uploads/2023/10/shell.jpg?cmd=ls -la

This confirmed a critical RCE vulnerability, allowing arbitrary command execution on the server with the privileges of the web server user (typically www-data or similar).

Server-Side Configuration and OVH Environment

The OVH environment, while robust, presented specific considerations. The Nginx configuration was crucial. We examined the Nginx virtual host configuration for the affected WordPress site to understand how it handled file uploads and served content from the upload directory.

server {
    listen 80;
    server_name your-wordpress-site.com;
    root /var/www/your-wordpress-site.com/html;
    index index.php index.html index.htm;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock; # Example PHP-FPM socket
    }

    # Critical section for uploads
    location ~* ^/wp-content/uploads/.*.(php|phtml|php3|php4|php5|php7|phps|shtml|inc|lib|exe|cgi|pl|py|sh)$ {
        deny all;
    }
}

The above Nginx configuration snippet includes a crucial directive: location ~* ^/wp-content/uploads/.*.(php|phtml|php3|php4|php5|php7|phps|shtml|inc|lib|exe|cgi|pl|py|sh) { deny all; }. This rule is designed to prevent the execution of PHP and other script files directly from the uploads directory. However, if the plugin bypasses this by uploading a file with a non-executable extension (like .jpg) and the server’s PHP handler is misconfigured to execute files based on content or other heuristics, the vulnerability can still be exploited. In this specific case, the plugin’s flaw was in its *own* validation, not necessarily a server-level misconfiguration, but the Nginx rule is a vital defense-in-depth measure.

We also checked the PHP configuration (php.ini) for any settings that might inadvertently allow script execution from upload directories, such as `disable_functions` or `open_basedir` directives. In this instance, the primary issue was the plugin’s lack of validation, not a server-wide PHP misconfiguration.

Mitigation Strategy: Patching and Hardening

The immediate and most critical mitigation was to update the “Advanced Media Uploader” plugin to its latest secure version. If an update was not available, the plugin would have been disabled or removed entirely.

Beyond patching the specific plugin, we implemented a multi-layered hardening strategy:

• Enhanced File Upload Validation: Ensured all file upload handlers (custom or plugin-based) perform rigorous server-side validation. This includes:
  • Checking the MIME type of the uploaded file against an allowed list (e.g., image/jpeg, image/png, application/pdf).
  • Performing a “magic byte” check to verify the file’s actual content signature.
  • Sanitizing filenames to remove potentially dangerous characters or extensions.
  • Storing uploaded files outside the webroot or in a directory where script execution is explicitly disabled.
• Nginx Configuration Hardening: Verified and strengthened the Nginx configuration to explicitly deny execution of scripts from the uploads directory, as shown previously. We also considered adding more restrictive rules for executable file extensions.
• PHP Configuration Review: Ensured php.ini settings like upload_tmp_dir were secure and that disable_functions was configured to prevent execution of dangerous system commands (e.g., system(), exec(), shell_exec(), passthru(), popen(), proc_open()).
• File Permissions: Reviewed and tightened file and directory permissions on the server. The web server user should only have write access to necessary directories (like upload folders) and not to core WordPress files or sensitive configuration files.
• Web Application Firewall (WAF): Deployed or configured a WAF (e.g., ModSecurity with OWASP Core Rule Set) to provide an additional layer of defense against common web attacks, including attempts to upload malicious files.
• Regular Security Audits: Scheduled recurring security audits of custom code and third-party plugins to proactively identify and address vulnerabilities.

Post-Mitigation Verification and Monitoring

After applying the patches and hardening measures, a comprehensive re-test was performed to ensure the RCE vulnerability was no longer exploitable. This involved attempting to upload various malicious file types and using different evasion techniques.

Furthermore, we implemented enhanced logging and monitoring:

• Nginx Access Logs: Configured Nginx to log detailed access information, including user agents, referrers, and request methods.
• PHP Error Logs: Ensured PHP error logging was enabled and directed to a secure location.
• Intrusion Detection System (IDS): Integrated server-level IDS to monitor for suspicious process activity or network connections.
• WordPress Security Plugins: Utilized robust WordPress security plugins (e.g., Wordfence, Sucuri Security) for file integrity monitoring, malware scanning, and brute-force protection.

This multi-faceted approach, combining immediate remediation with long-term hardening and continuous monitoring, successfully secured the high-traffic WordPress enterprise stack against the identified RCE vulnerability and significantly reduced the attack surface.