Atomic Edge analysis of CVE-2025-69364:
The Breeze WordPress cache plugin, versions up to and including 2.2.21, contains a missing authorization vulnerability in its REST API cache purge endpoint. This flaw allows unauthenticated attackers to trigger a cache purge operation, which is a privileged administrative action.

The root cause is a flawed conditional authorization check in the `breeze_clear_cache` function within the `class-breeze-api.php` file. The function checked if the `breeze-secure-api` option was enabled and if a provided `key` parameter matched a stored token. However, the logic allowed the function to proceed if the `breeze-secure-api` option was disabled, regardless of the token’s validity. The vulnerable code at line 28 performed the check `if ( $this->options[“breeze-secure-api”] && $this->options[“breeze-api-token”] != $request->get_param( ‘key’ ) )`. This meant that when `breeze-secure-api` was set to ‘0’, the entire condition evaluated to false, bypassing the token verification and the 403 error response.

An attacker exploits this by sending a GET or POST request to the WordPress REST API endpoint `/wp-json/breeze/v1/cache`. No authentication cookies, nonces, or user sessions are required. The attacker only needs to ensure the target site has the Breeze API enabled. The request can be sent with or without a `key` parameter, as the vulnerable logic will ignore it when the insecure default configuration is in place.

The patch removes the `breeze-secure-api` configuration option entirely. The fix deletes the conditional check for this option in `class-breeze-api.php` line 28, changing it to `if ( $this->options[“breeze-api-token”] != $request->get_param( ‘key’ ) )`. This makes token verification mandatory for all API requests. The patch also removes the `breeze-secure-api` option from the plugin’s database schema, default settings, admin interface, and configuration files, as shown by the deletions across `breeze.php`, `breeze-admin.php`, `breeze-configuration.php`, and `advanced-tab.php`. The token generation length was also increased from 12 to 32 characters.

Successful exploitation allows an unauthenticated attacker to purge the site’s cache. This constitutes a denial-of-service condition by removing cached pages, forcing the server to regenerate content and increasing load. Repeated attacks can degrade site performance and availability. The attack also represents an unauthorized administrative action, violating the integrity of the site’s caching system.