CVE-2024-56064: WP SuperBackup File Upload RCE Vulnerability

CVE-2024-56064 Overview

CVE-2024-56064 is a critical unrestricted file upload vulnerability (CWE-434) affecting the WP SuperBackup WordPress plugin by Azzaroco. This vulnerability allows unauthenticated attackers to upload malicious files, including web shells, directly to the web server. The flaw stems from insufficient validation of file types during the upload process, enabling attackers to bypass security controls and achieve remote code execution on vulnerable WordPress installations.

Critical Impact

Unauthenticated attackers can upload web shells to WordPress sites running WP SuperBackup versions 2.3.3 and earlier, potentially leading to complete server compromise, data theft, and persistent backdoor access.

Affected Products

• WP SuperBackup plugin versions through 2.3.3
• WordPress installations using vulnerable WP SuperBackup versions

Discovery Timeline

• 2024-12-31 - CVE CVE-2024-56064 published to NVD
• 2024-12-31 - Last updated in NVD database

Technical Details for CVE-2024-56064

Vulnerability Analysis

This vulnerability represents a severe security flaw in WordPress backup plugin functionality. The WP SuperBackup plugin fails to properly validate file types during upload operations, allowing attackers to submit files with dangerous extensions such as .php, .phtml, or other executable formats. Once uploaded, these malicious files can be accessed directly via the web server, granting the attacker arbitrary code execution capabilities within the context of the web application.

The unauthenticated nature of this vulnerability significantly increases its risk profile, as no prior authentication or user interaction is required to exploit the flaw. Attackers can remotely target any WordPress site with the vulnerable plugin installed, making this an attractive target for automated exploitation campaigns.

Root Cause

The root cause of CVE-2024-56064 is the absence of proper file type validation in the WP SuperBackup plugin's upload handling functionality. The plugin does not adequately verify that uploaded files are of safe, expected types (such as database dumps or configuration files), nor does it restrict uploads to non-executable formats. This allows attackers to bypass intended restrictions and upload arbitrary PHP files that the web server will execute when accessed.

Attack Vector

The attack is network-based and can be executed remotely without any authentication. An attacker crafts a malicious HTTP request to the vulnerable upload endpoint, submitting a PHP web shell disguised as a legitimate backup file or exploiting the lack of file type checks entirely. The attack flow typically involves:

1. Identifying a WordPress site with WP SuperBackup installed
2. Crafting a POST request to the vulnerable upload endpoint with a PHP web shell payload
3. The server accepts and stores the malicious file without proper validation
4. The attacker accesses the uploaded web shell via a direct URL
5. The attacker gains remote code execution on the server

For technical details on this vulnerability, refer to the Patchstack Vulnerability Report.

Detection Methods for CVE-2024-56064

Indicators of Compromise

• Unexpected PHP files appearing in WordPress upload directories or plugin folders
• New files with suspicious names (e.g., random strings, base64-encoded names, or common web shell names like shell.php, cmd.php, c99.php)
• Web server access logs showing POST requests to WP SuperBackup upload endpoints followed by GET requests to unusual file paths
• Unusual outbound network connections from the web server
• Modified file timestamps in WordPress directories that don't correlate with legitimate administrative activity

Detection Strategies

• Monitor web server access logs for suspicious POST requests to WP SuperBackup endpoints
• Implement file integrity monitoring (FIM) on WordPress directories to detect unauthorized file additions
• Deploy web application firewalls (WAF) with rules to block common web shell upload patterns
• Use SentinelOne's Singularity platform to detect and block malicious file drops and post-exploitation behavior
• Regularly scan WordPress installations for known web shell signatures and suspicious PHP files

Monitoring Recommendations

• Enable verbose logging on web servers to capture full request details including POST body content
• Configure alerts for new PHP file creation in WordPress directories outside of normal update windows
• Implement network monitoring to detect command-and-control traffic from compromised web servers
• Monitor WordPress plugin directories for files that don't match expected plugin structures

How to Mitigate CVE-2024-56064

Immediate Actions Required

• Immediately deactivate and remove the WP SuperBackup plugin if running version 2.3.3 or earlier
• Audit WordPress installations for any signs of compromise, including unexpected PHP files
• Review web server access logs for exploitation attempts against WP SuperBackup endpoints
• Scan the server for known web shell signatures and remove any malicious files discovered
• Consider restoring from a known-clean backup if compromise is suspected

Patch Information

Organizations should check for an updated version of WP SuperBackup that addresses this vulnerability. Review the Patchstack Vulnerability Report for the latest patch status and remediation guidance. If no patch is available, consider switching to an alternative backup solution with a stronger security track record.

Workarounds

• Remove or deactivate the WP SuperBackup plugin until a patched version is available
• Implement WAF rules to block POST requests to WP SuperBackup upload endpoints
• Restrict access to WordPress administrative functions via IP allowlisting
• Use .htaccess rules to deny direct execution of PHP files in upload directories
• Deploy application-level controls to validate and sanitize all file uploads

# Example .htaccess rule to prevent PHP execution in uploads directory
# Place this in wp-content/uploads/.htaccess
<FilesMatch "\.(?:php[0-9]?|phtml|phar)$">
    Require all denied
</FilesMatch>