CVE-2024-9047

What it actually does

The WordPress File Upload plugin is vulnerable to unauthenticated path traversal in wfu_file_downloader.php in versions up to and including 4.24.11 when the WordPress site runs on PHP 7.4 or earlier. A remote attacker can manipulate file path input handled by the downloader component so that path resolution escapes the intended upload directory. Depending on the request path and plugin behavior, this can allow reading sensitive files such as WordPress configuration files, PHP source files, system files, or uploaded content, and may also allow deletion of files outside the intended directory.

Why it matters to the business

Successful exploitation can expose database credentials, application secrets, user-uploaded data, configuration files, and other sensitive content stored on the web server. If file deletion is abused, the attacker may disrupt the website, remove important files, break plugin or WordPress functionality, or create an outage. The risk is elevated because exploitation is weaponized, requires no authentication, has a very high EPSS score, and targets a widely deployed WordPress plugin class that is commonly scanned at internet scale.

How an attack unfolds

An attacker first identifies a WordPress site with the WordPress File Upload plugin installed and reachable over the internet. They then check whether the vulnerable downloader script is accessible under the plugin directory, commonly beneath /wp-content/plugins/wp-file-upload/. If the site is running PHP 7.4 or earlier and the plugin version is 4.24.11 or older, the attacker sends crafted HTTP requests to wfu_file_downloader.php containing directory traversal sequences or encoded traversal variants. The vulnerable code resolves the attacker-supplied path outside of the intended upload directory. The attacker can then attempt to retrieve sensitive files such as wp-config.php, server configuration files, local OS files, logs, or application source code. If deletion functionality is reachable through the same vulnerable path handling, the attacker may delete files outside the expected upload location, causing data loss or operational disruption. Stolen WordPress configuration data may enable follow-on compromise, including database access, credential reuse, administrative takeover, web shell placement through other weaknesses, or broader hosting-account compromise.

How to fix it

Upgrade the WordPress File Upload plugin to a vendor-fixed release newer than 4.24.11 as soon as one is available. If no fixed release is available or the plugin is not required, disable and remove the plugin. Because exploitation requires PHP 7.4 or earlier, upgrade PHP to a supported version later than 7.4; this should be treated as a defense-in-depth control and not a substitute for patching or removing the vulnerable plugin. Restrict direct web access to plugin helper scripts where operationally possible, especially /wp-content/plugins/wp-file-upload/wfu_file_downloader.php. Apply WAF or web server rules to block traversal payloads, including encoded forms of ../ and attempts to access sensitive files such as wp-config.php. Ensure file permissions prevent the web server process from reading or deleting files it does not need. Rotate any credentials stored in files that may have been exposed, especially WordPress database credentials in wp-config.php, if exploitation is suspected.

How to confirm the fix worked

Confirm that the WordPress File Upload plugin is not installed, is disabled, or is upgraded to a version newer than 4.24.11. Confirm that PHP is upgraded beyond 7.4 and is on a supported branch. Use WordPress administrative inventory, file-system inspection, or WP-CLI to verify the plugin version. Check that direct unauthenticated requests to /wp-content/plugins/wp-file-upload/wfu_file_downloader.php are denied, return a safe error, or are no longer reachable. Test WAF or web server controls with benign traversal-pattern requests and verify they are blocked before reaching PHP. Review file permissions to ensure the web server user cannot read sensitive system files beyond normal requirements or delete files outside intended upload directories. If credentials were rotated, validate that old credentials no longer authenticate.

Typical attack path

1. Scan public WordPress sites for the WordPress File Upload plugin and the presence of /wp-content/plugins/wp-file-upload/wfu_file_downloader.php.
2. Confirm the target is likely vulnerable by checking plugin exposure and whether the site is using PHP 7.4 or earlier.
3. Send unauthenticated crafted requests to the downloader endpoint with path traversal sequences or encoded traversal variants.
4. Read files outside the intended upload directory, prioritizing WordPress configuration, credentials, logs, and system files.
5. Use any recovered credentials or secrets for follow-on access to the WordPress database, admin interfaces, hosting control plane, or adjacent services.
6. Optionally abuse file deletion behavior to remove application files, uploaded content, logs, or other files accessible to the web server process.

How to detect it

Review HTTP access logs, WAF logs, CDN logs, reverse proxy logs, PHP-FPM logs, and WordPress security plugin logs for unauthenticated requests to the WordPress File Upload downloader script, especially requests containing ../ traversal sequences, URL-encoded traversal, double-encoded traversal, absolute paths, or sensitive filenames. Focus on requests to /wp-content/plugins/wp-file-upload/wfu_file_downloader.php returning HTTP 200, 206, 500, or unusually large response sizes, as these may indicate successful file retrieval or error-driven probing. Look for repeated requests from the same source IP cycling through targets such as wp-config.php, /etc/passwd, /proc/self/environ, web server logs, .htaccess, or Windows files. Investigate requests followed by suspicious logins, database connections, plugin/theme editor use, new administrator accounts, unexpected PHP files, or outbound connections from the web server. For deletion impact, compare file integrity monitoring, WordPress core checksums, plugin/theme directories, and upload directories against known-good backups and timestamps. Also review PHP error logs for failed include/open/read/unlink operations involving traversal or paths outside the plugin upload directory.

• /wp-content/plugins/wp-file-upload/wfu_file_downloader.php
• wfu_file_downloader.php
• ../
• ..%2f
• %2e%2e%2f
• %2e%2e/
• ..%252f
• %252e%252e%252f
• ..\
• ..%5c
• %2e%2e%5c
• wp-config.php
• /etc/passwd
• /etc/shadow
• /proc/self/environ
• /proc/self/cmdline
• .htaccess
• web.config
• C:\Windows\win.ini
• C:%5CWindows%5Cwin.ini
• wfu_file_downloader.php?
• GET /wp-content/plugins/wp-file-upload/wfu_file_downloader.php
• POST /wp-content/plugins/wp-file-upload/wfu_file_downloader.php

What your security team should do

• Prioritize remediation immediately because exploitation is weaponized, unauthenticated, remotely reachable, and has a very high EPSS probability.
• Inventory all WordPress sites for the WordPress File Upload plugin and identify versions up to and including 4.24.11.
• Identify sites running PHP 7.4 or earlier and prioritize them first, because that runtime condition is required for known exploitation.
• Upgrade the plugin to a fixed version newer than 4.24.11, or remove the plugin if it is not business-critical.
• Upgrade PHP to a supported version later than 7.4 across affected WordPress deployments.
• Add WAF or web server rules blocking requests to wfu_file_downloader.php that contain traversal patterns, encoded traversal, or sensitive filename targets.
• Review historical web access logs for exploitation attempts and successful responses before and after remediation.
• If wp-config.php or other credential-bearing files may have been accessed, rotate WordPress database credentials, salts, API keys, and any exposed secrets.
• Review file integrity and backups for unexpected deletion or modification of WordPress core files, plugin files, uploads, and configuration files.
• Increase monitoring for follow-on activity such as suspicious administrator logins, database access anomalies, new plugin installations, unexpected PHP files, or web shell indicators.