CVE-2026-2128: WordPress Breeze Plugin Info Disclosure

CVE-2026-2128 Overview

CVE-2026-2128 affects the Breeze caching plugin for WordPress in all versions up to and including 2.5.2. The plugin improperly verifies the wordpress_logged_in_ cookie inside inc/cache/execute-cache.php when the "Cache Logged-in Users" setting is enabled. An unauthenticated attacker can supply a crafted cookie such as wordpress_logged_in_fake=admin|fake to retrieve cached HTML originally generated for an administrator. This exposes private posts, the Admin Bar, WordPress nonces, and other content visible only to authenticated users. The flaw is categorized as Information Exposure under [CWE-200].

Critical Impact

Unauthenticated attackers can read administrator-only cached pages, including private post content and valid WordPress nonces, by forging a session cookie value.

Affected Products

• Breeze plugin for WordPress, all versions through 2.5.2
• WordPress sites with the Breeze "Cache Logged-in Users" setting enabled
• Fixed in Breeze 2.5.3

Discovery Timeline

• 2026-05-29 - CVE-2026-2128 published to the National Vulnerability Database
• 2026-05-29 - Last updated in NVD database

Technical Details for CVE-2026-2128

Vulnerability Analysis

The Breeze plugin generates per-user cache files for logged-in visitors when the "Cache Logged-in Users" feature is active. To map a request to a cached file, the plugin reads the wordpress_logged_in_ cookie and parses the username from the username|hash structure using substr(). The plugin then loads the cached HTML associated with that username and returns it to the requester.

The vulnerability stems from missing session validation. The plugin never calls WordPress core functions to verify the cookie's cryptographic signature, expiration, or association with a valid session. An attacker who supplies any string in the username position receives whatever cached content already exists for that user.

This exposes data that should remain restricted, including private and draft post content, the rendered Admin Bar, and active WordPress nonces. Leaked nonces extend the impact because they can be reused in follow-on CSRF or privileged action attacks before they expire.

Root Cause

The root cause is improper verification of an authentication artifact. The handler in inc/cache/execute-cache.php treats the cookie value as a trusted lookup key rather than an authenticated credential. WordPress core normally validates wordpress_logged_in_ cookies through wp_validate_auth_cookie(), which checks the HMAC signature, but Breeze bypasses that step for cache routing.

Attack Vector

The attack is fully remote and unauthenticated. An attacker sends an HTTP request to a vulnerable WordPress site and attaches a forged cookie such as Cookie: wordpress_logged_in_fake=admin|fake. If a cache file for the admin user exists, the plugin returns its contents in the response. No user interaction, authentication, or elevated privileges are required.

The vulnerability is described in prose only because no verified proof-of-concept code has been published. Technical detail is available in the Wordfence Vulnerability Analysis and in the corrected logic shown in the Breeze 2.5.3 Change Set.

Detection Methods for CVE-2026-2128

Indicators of Compromise

• HTTP requests carrying wordpress_logged_in_ cookies with unusual suffixes or non-hex hash segments, for example wordpress_logged_in_fake=admin|fake.
• Unauthenticated client IPs receiving responses that contain administrator-only markup such as the WordPress Admin Bar (id="wpadminbar") or data-wp-nonce attributes.
• Anomalous cache hit patterns where the same source IP enumerates multiple usernames in the cookie field.

Detection Strategies

• Inspect web server and reverse proxy logs for requests containing forged wordpress_logged_in_* cookie names not issued by the site.
• Compare response body fingerprints between authenticated and unauthenticated sessions to identify cases where admin-only content is served to unauthenticated clients.
• Audit installed plugin versions across WordPress fleets to flag Breeze installations at 2.5.2 or earlier with the "Cache Logged-in Users" option enabled.

Monitoring Recommendations

• Forward WordPress access logs to a centralized analytics platform and alert on cookie values that do not match WordPress core's HMAC format.
• Monitor for spikes in requests targeting the site root or common admin landing pages with attached wordpress_logged_in_ cookies from unauthenticated sources.
• Track Breeze plugin version inventory and alert when sites remain below 2.5.3.

How to Mitigate CVE-2026-2128

Immediate Actions Required

• Update the Breeze plugin to version 2.5.3 or later on every WordPress instance.
• If immediate updating is not possible, disable the "Cache Logged-in Users" setting in Breeze to remove the vulnerable code path.
• Rotate any WordPress nonces tied to sensitive actions and review private or draft posts that may have been disclosed.

Patch Information

The vendor fix is published in Breeze 2.5.3. The corrected logic validates the wordpress_logged_in_ cookie before serving cached content. Review the upstream fix in the Breeze 2.5.3 Change Set and the version diff between 2.5.2 and 2.5.3.

Workarounds

• Disable the "Cache Logged-in Users" option in the Breeze settings until the plugin is upgraded.
• Deactivate the Breeze plugin entirely on sites where logged-in caching cannot be turned off through the admin interface.
• Add a web application firewall rule to block requests where the wordpress_logged_in_ cookie value does not match the expected username|hash|expiration|token format.
• Purge existing Breeze cache files to remove any stored administrator-rendered pages before applying the update.