CVE-2024-12008: W3 Total Cache Information Disclosure

CVE-2024-12008 Overview

CVE-2024-12008 is an information exposure vulnerability in the W3 Total Cache plugin for WordPress. The flaw affects all versions up to and including 2.8.1. The plugin writes diagnostic data to a publicly accessible debug log file when the debug feature is enabled. Unauthenticated attackers can request this log directly over the network and read its contents. The log can contain nonce values, internal paths, and other sensitive runtime data. Recovered nonce values can then be reused in follow-on Cross-Site Request Forgery (CSRF) attacks against authenticated users. The debug feature is disabled by default, which limits exposure to sites that have explicitly enabled it. The issue is tracked under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor).

Critical Impact
Unauthenticated remote attackers can read W3 Total Cache debug logs containing nonces and other sensitive data, enabling CSRF chaining against WordPress sites.

Affected Products

Boldgrid W3 Total Cache plugin for WordPress, all versions through 2.8.1
WordPress sites with the W3 Total Cache debug feature enabled
Any deployment serving the plugin's log directory through the web root

Discovery Timeline

2025-01-14 - CVE-2024-12008 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-12008

Vulnerability Analysis

The W3 Total Cache plugin provides full-site caching, minification, and CDN integration for WordPress. When the optional debug feature is enabled, the plugin writes diagnostic output to a log file via the Util_Debug helper. The log path resolves through Util_Environment to a location under the plugin's cache directory that the web server serves without authentication. Any unauthenticated client that knows or guesses the log path can issue an HTTP GET request and retrieve the file contents.

Debug output captured by the plugin includes request context generated during cache operations. This context can embed WordPress nonce tokens, internal file paths, query parameters, and other state. Nonces are short-lived but valid for hours, which gives an attacker a usable window to craft CSRF requests that pass nonce checks. The attacker still needs a victim session, but the leaked nonce removes a key protection that would otherwise block forged actions.

The vulnerability does not allow code execution or direct data modification. The impact is confined to confidentiality and to follow-on attacks that depend on leaked tokens.

Root Cause

The debug log is written to a directory that is reachable over HTTP and is not protected by access controls such as .htaccess denies, authentication, or randomized filenames. Sensitive runtime data, including nonces, is included in log entries without redaction. Source references for the affected logic are available in the plugin tree at Util_Debug.php and Util_Environment.php.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker enumerates the plugin's known log path under the WordPress content directory and requests the file. If the debug feature is enabled and the file is present, the server returns its contents. The attacker parses the response for nonce values and other identifiers and then uses them to construct CSRF payloads delivered through phishing, malvertising, or attacker-controlled pages. See the Wordfence Vulnerability Report for additional technical context.

Detection Methods for CVE-2024-12008

Indicators of Compromise

Web server access log entries showing unauthenticated GET requests to paths under /wp-content/cache/ or /wp-content/plugins/w3-total-cache/ that return files with a .log extension.
Requests for known W3 Total Cache debug filenames from unfamiliar IP addresses or automated scanners.
Subsequent state-changing POST requests that succeed with nonces matching values previously emitted to the debug log.

Detection Strategies

Inspect the WordPress installation for the W3 Total Cache plugin and verify whether the debug option is enabled in plugin settings.
Search the filesystem for plugin debug log files and confirm whether they are reachable through the web server.
Correlate web access logs with WordPress audit logs to identify nonce reuse from external sources.

Monitoring Recommendations

Alert on any HTTP 200 response serving files with .log extensions from WordPress content directories.
Monitor for scanning patterns that enumerate plugin paths across multiple WordPress sites.
Track plugin version inventory across managed WordPress estates and flag installations running 2.8.1 or earlier.

How to Mitigate CVE-2024-12008

Immediate Actions Required

Update the W3 Total Cache plugin to a version later than 2.8.1 as soon as the vendor patch is available.
Disable the debug feature in W3 Total Cache settings if it is not actively required.
Delete existing debug log files from the plugin cache directory and rotate any WordPress secrets and session tokens that may have been exposed.

Patch Information

Boldgrid addresses the issue in releases after 2.8.1. Review the Wordfence Vulnerability Report and the plugin changelog on WordPress.org for the fixed version and confirm the upgrade across all managed sites.

Workarounds

Disable the W3 Total Cache debug option until the plugin is updated.
Add web server rules that deny direct access to .log files under wp-content, for example through an .htaccess deny directive or an equivalent nginx location block.
Restrict access to the WordPress wp-content/cache directory at the web server or WAF layer to block unauthenticated retrieval of log artifacts.

bash

# Apache .htaccess example to block direct access to log files
<FilesMatch "\.log$">
    Require all denied
</FilesMatch>

# Nginx equivalent
location ~* \.log$ {
    deny all;
    return 403;
}