CVE-2026-79713 in Breeze Cache Plugin
Summary
by MITRE • 09/18/2026
The Breeze Cache WordPress plugin before 2.5.15 does not include a set of tracking-related query parameters in its page-cache key while still caching pages requested with them, allowing unauthenticated attackers to have a page rendered under their own request context stored under, and served from, the clean URL's cache entry to every subsequent visitor.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/18/2026
The vulnerability identified in Breeze Cache versions prior to 2.5.15 represents a critical flaw in how dynamic content is handled within server-side caching mechanisms for WordPress environments. The core issue stems from an inconsistency between request identification and cache storage logic. Specifically, the plugin fails to incorporate specific tracking-related query parameters into the unique key used to generate cached page versions. While these parameters are essential for distinguishing user-specific contexts such as session identifiers or analytics cookies, their omission means that requests containing them are treated identically to clean requests without any identifying data during the caching process. This architectural oversight allows unauthenticated attackers to exploit the cache system by injecting tracking parameters into their HTTP requests, thereby triggering the storage of a page version rendered under their specific request context rather than a generic public one.
From a technical perspective, this flaw facilitates an unauthorized information disclosure and potential session hijacking scenario through cache poisoning techniques. When an attacker accesses a cached page with unique query strings or headers that influence server-side logic, such as personalized content generation or authentication checks, the resulting HTML output is stored in the global cache pool under a generic key associated with the clean URL path. Consequently, when subsequent legitimate visitors access the same URL without those specific tracking parameters, they receive the previously cached response intended for the attacker's context. This effectively bypasses standard WordPress security boundaries because the caching layer serves content that was generated based on an unauthenticated or malicious request state to authenticated users who may have sensitive data displayed in their personalized views.
The operational impact of this vulnerability is severe, particularly for websites relying heavily on dynamic personalization, e-commerce functionality, or user-specific dashboards. Attackers can potentially view private information belonging to other users, such as order history, account details, or restricted content that should only be visible after authentication. Furthermore, if the cached page contains session tokens or CSRF protection mechanisms tied to the attacker's initial request context, it could lead to broader security compromises including cross-site scripting vectors or privilege escalation attempts where the victim's browser executes code in a state intended for another user. This type of attack aligns with CWE-359, which describes exposure of private information through improper handling of sensitive data, and falls under the ATT&CK technique T1078, specifically involving valid accounts or impersonation to gain unauthorized access to resources via system configuration errors.
Mitigation strategies must focus on ensuring that caching mechanisms strictly differentiate between public static content and user-specific dynamic content. Administrators should immediately update the Breeze Cache plugin to version 2.5.15 or later where this logic has been corrected to include necessary tracking parameters in cache keys. In environments where immediate patching is not feasible, implementing WAF rules that exclude URLs with specific query strings from caching can provide temporary relief. Additionally, configuring WordPress and web servers to set appropriate Cache-Control headers such as no-cache for pages containing session-related data ensures that dynamic responses are always generated fresh per request rather than served from a shared pool. Regular auditing of cache configurations against industry standards like OWASP guidelines for secure coding practices is essential to prevent similar misconfigurations in future deployments.