CVE-2026-79713: Breeze Cache WordPress Auth Bypass Flaw

CVE-2026-79713 Overview

The Breeze Cache WordPress plugin before version 2.5.15 contains a cache key handling flaw that enables web cache poisoning. The plugin fails to include tracking-related query parameters in its page-cache key while still caching pages requested with those parameters. Unauthenticated attackers can trigger a page render under their own request context and have it stored under the clean URL's cache entry. Every subsequent visitor to the clean URL then receives the attacker-influenced cached response. The issue is classified under [CWE-444] (Inconsistent Interpretation of HTTP Requests).

Critical Impact

Attackers can poison the shared page cache of any site running vulnerable Breeze Cache, causing all subsequent visitors to receive attacker-influenced content from the clean URL.

Affected Products

• Breeze Cache WordPress plugin versions prior to 2.5.15
• WordPress sites using Breeze for page caching
• Multi-tenant WordPress hosts serving cached pages to anonymous visitors

Discovery Timeline

• 2026-09-18 - CVE-2026-79713 published to the National Vulnerability Database
• 2026-09-18 - Last updated in NVD database

Technical Details for CVE-2026-79713

Vulnerability Analysis

Breeze is a page-caching plugin that stores rendered HTML responses keyed by URL. The cache layer normalizes requests so that a URL like /product returns the same cached response regardless of certain query parameters. The vulnerable versions treat tracking parameters, such as those used by marketing and analytics platforms, as non-significant for cache-key generation but still allow those requests to populate the cache entry for the clean URL.

An attacker requests the target URL with tracking parameters that influence server-side rendering. The response Breeze stores is bound to the attacker's request context. Because the cache key strips the tracking parameters, subsequent visitors requesting the clean URL are served the attacker-controlled cached response until the entry expires.

The result is an unauthenticated, network-reachable cache poisoning primitive. Depending on which server-side rendering paths are influenced by the parameters, the impact ranges from content spoofing and open redirect chaining to reflected script execution served to every visitor.

Root Cause

The root cause is inconsistency between cache-key normalization and cache-population logic. Breeze excludes tracking query parameters from the key used to look up cached pages, yet does not exclude those requests from writing to the cache. This mismatch [CWE-444] permits one client to seed a cache entry that other clients retrieve under a different, canonical key.

Attack Vector

Exploitation requires only network access to a WordPress site running a vulnerable Breeze version. The attacker crafts a request to a cacheable page with tracking query parameters that alter the rendered output. Once the response is cached, the attacker waits for legitimate traffic. Any user requesting the clean URL receives the poisoned response. No authentication, user interaction, or elevated privileges are required.

Refer to the WPScan Vulnerability Report for technical details on the affected code paths.

Detection Methods for CVE-2026-79713

Indicators of Compromise

• Unexpected content, redirects, or scripts appearing in cached pages served from clean URLs
• Access-log entries showing repeated anonymous requests to cacheable pages with tracking query parameters preceding user reports of altered content
• Cache-storage entries where the stored response body references query-parameter-derived values not present in the request key
• User reports of session anomalies, phishing content, or unexpected redirects on otherwise static pages

Detection Strategies

• Audit installed Breeze plugin versions across managed WordPress sites and flag any instance below 2.5.15
• Compare rendered output for a canonical URL against the same URL requested with common tracking parameters to detect divergent responses reaching the cache
• Monitor web application firewall logs for suspicious query-parameter payloads followed by anonymous traffic surges to the same base URL

Monitoring Recommendations

• Enable verbose logging on the caching layer to record which request populated each cache entry
• Alert on cache entries whose response bodies contain reflected query-parameter values
• Track HTTP 3xx and content-length anomalies on high-traffic cached pages to surface unexpected variant responses

How to Mitigate CVE-2026-79713

Immediate Actions Required

• Upgrade the Breeze plugin to version 2.5.15 or later on all WordPress sites
• Purge the existing page cache after upgrading to evict any previously poisoned entries
• Review recent cached content for spoofed links, redirects, or injected scripts served to visitors

Patch Information

The issue is fixed in Breeze version 2.5.15. The patched release includes tracking-related query parameters in the cache key so that requests carrying those parameters no longer share a cache entry with the clean URL. See the WPScan Vulnerability Report for advisory details.

Workarounds

• Disable Breeze page caching until the plugin can be upgraded
• Configure an upstream reverse proxy or CDN to strip tracking query parameters before requests reach WordPress
• Add web application firewall rules that block anonymous requests with tracking parameters to cacheable endpoints
• Shorten cache TTLs to reduce the window during which a poisoned entry is served

# Example: strip tracking parameters at an Nginx reverse proxy before Breeze sees them
if ($args ~ (^|&)(utm_[a-z]+|fbclid|gclid|mc_[a-z]+)=) {
    set $clean_args "";
    rewrite ^(.*)$ $1? permanent;
}