ANALYSIS · df342fc8· FINISHED 2026-06-13 · PATCHDIFF

w3-total-cache2.9.3 → 2.9.4✓ COMPLETED

Files29

Vulnerable10

True positives0

CVE matched2

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2026-5032

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 29 CVE 2 Vuln 10

SORT

2 files · page 1/1

BrowserCache_Plugin.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2026-5032

#%!d(float64=001)

Generic_Plugin.php

AI: 3 vulnerabilities

CWE-20: Improper Input ValidationCWE-755: Improper Handling of Exceptional ConditionsCWE-284: Improper Access Control CVE-2026-5032

#%!d(float64=013)

1–2 of 2

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2026-5032

Security writeup for CVE-2026-5032

✓ 2 FILES

## The Exploit

An unauthenticated attacker with network access to any WordPress site running W3 Total Cache ≤ 2.9.3 can leak the `W3TC_DYNAMIC_SECURITY` token by crafting a single HTTP request with a spoofed User-Agent header. Once the token is obtained, arbitrary PHP code execution follows.

```http
GET / HTTP/1.1
Host: target.wordpress.local
User-Agent: W3 Total Cache
Connection: close
```

The response will contain unprocessed `mfunc` and `mclude` HTML comments in the page source, including the plaintext `W3TC_DYNAMIC_SECURITY` token embedded within them:

```html

<div>Dynamic fragment content</div>

```

An attacker observes raw, unprocessed dynamic fragment markers that should have been stripped during the output buffering pipeline. With the exposed token, the attacker can craft valid `mfunc` tags to execute arbitrary PHP on the server by POST-ing a request to `wp-admin/admin-ajax.php` with the token and malicious code in the fragment payload.

## What the Patch Did

**Before**

```php
$http_user_agent = isset( $_SERVER['HTTP_USER_AGENT'] ) ? sanitize_text_field( wp_unslash( $_SERVER['HTTP_USER_AGENT'] ) ) : '';
if ( stristr( $http_user_agent, W3TC_POWERED_BY ) !== false ) {
    return false;
}
```

**After**

```php
// Do not skip output buffering based on User-Agent: the value is client-controlled.
// A request claiming "W3 Total Cache" would previously bypass ob_callback, skipping
// page-cache processing and leaking W3TC_DYNAMIC_SECURITY from unprocessed mfunc/mclude.

return true;
```

The patch removes the conditional logic that checked the `HTTP_USER_AGENT` header against the constant `W3TC_POWERED_BY` (the string "W3 Total Cache"). The old code returned `false` to skip output buffering initialization when that header was present; the fixed code unconditionally returns `true`, ensuring the output buffering callback (`ob_callback`) always runs. This callback is responsible for stripping sensitive internal tokens and processing dynamic fragments before the response is sent to the client.

## Root Cause

**CWE-20: Improper Input Validation**

The vulnerability flows from the `$_SERVER['HTTP_USER_AGENT']` HTTP request header — a fully client-controlled value — directly into a security-critical control-flow decision. The `sanitize_text_field()` function applied to the header performs no validation; it only escapes the value for safe HTML display. Sanitization is not validation. The attacker-controlled header reaches the `stristr()` function, which compares it against `W3TC_POWERED_BY`. If the comparison succeeds, the entire output buffering pipeline is bypassed by returning `false` from the `can_ob()` method, causing the `ob_callback()` method (which strips the security token) to never execute. This crosses the trust boundary between the untrusted client and the trusted server-side processing pipeline without any authentication, capability check, or cryptographic proof that the request originates from W3 Total Cache infrastructure (which would be nonsensical anyway — the User-Agent header is sent *by* the client making the request, not by W3 Total Cache).

## Why It Works

The load-bearing line is the removal of the `stristr()` condition itself — if it remained, the bypass would still be exploitable. The comment lines added by the patch serve a critical function: they document *why* User-Agent must never control output buffering, preventing future maintainers from re-introducing the same flaw under the assumption that "we just need better validation." The fix also reflects an architectural change: by unconditionally calling `ob_start( array( $this, 'ob_callback' ) )` in the revised `Generic_Plugin.php` initialization, the callback is guaranteed to execute and process all output before transmission. The engineer added the comment to encode the security policy ("client-controlled headers never drive security decisions") as a persistent reminder in the codebase. Without that comment, a future contributor might reasonably ask "why can't we just regex-validate the User-Agent better?" and miss the fundamental principle being enforced.

## Hardening Checklist

- **Never use `$_SERVER['HTTP_USER_AGENT']` or any HTTP header for security decisions.** These values are client-controlled and spoofable. Use `wp_get_current_user()` and `current_user_can()` instead for authentication and authorization gates.
- **Do not confuse sanitization with validation.** `sanitize_text_field()`, `esc_attr()`, and similar WordPress functions prepare data for *output*, not for *security decisions*. Use explicit validation functions like `in_array()` with strict typing, `preg_match()` with anchored patterns, or dedicated libraries like `filter_var()` before making control-flow decisions.
- **Encode security policies in comments alongside code.** When you remove a "seemingly reasonable" check, document the threat model (e.g., "User-Agent is spoofable") so maintainers understand the principle, not just the current implementation.
- **Test output buffering bypasses explicitly.** Add integration tests that verify `ob_callback()` is always invoked by inspecting presence/absence of internal tokens in the final response across different request types and headers.
- **Use defense-in-depth for cryptographic tokens.** Even if the User-Agent bypass is fixed, the `W3TC_DYNAMIC_SECURITY` token should be rate-limited, nonce-based (one-time use), or short-lived (session-scoped) rather than static and long-lived.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-5032

CVE CVE-2026-5032

PRODUCT w3-total-cache

AFFECTED ≤ 2.9.3

FIXED IN 2.9.4

STATUS Generated

Security writeup · CVE-2026-5032

Source files · 2

BrowserCache_Plugin.php Linked

Generic_Plugin.php Linked

↗ NVD