CLP Varnish Cache <= 1.0.2 - Missing Authorization

This research plan focuses on identifying and exploiting a missing authorization vulnerability in the CLP Varnish Cache plugin (<= 1.0.2). The vulnerability allows unauthenticated attackers to trigger cache purging, which is an administrative action.

---

1. Vulnerability Summary

• ID: CVE-2026-24525
• Plugin: CLP Varnish Cache (slug: clp-varnish-cache)
• Vulnerable Version: <= 1.0.2
• Vulnerability Type: Missing Authorization
• Description: The plugin registers a function responsible for purging the Varnish cache via WordPress hooks (likely AJAX or admin_init). This function fails to implement current_user_can() checks, and either intentionally or accidentally permits unauthenticated access (via wp_ajax_nopriv_ or by using a hook that fires for all users).

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php (most likely) or /wp-admin/admin-post.php.
• Action Name: Likely clp_varnish_purge_all or clp_purge_cache (inferred from plugin name).
• Parameters: action=clp_varnish_purge_all (POST/GET).
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active and configured with a Varnish server (though the purge command will likely be attempted regardless of successful connection).

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an AJAX action in the main plugin file or an includes file:
   add_action( 'wp_ajax_nopriv_clp_varnish_purge_all', 'clp_varnish_purge_all_callback' );
2. Vulnerable Function: The callback (e.g., clp_varnish_purge_all_callback) is executed.
3. Missing Check: The function performs logic (e.g., sending a PURGE request to a local Varnish instance or calling a system command) without verifying the requester's capabilities via current_user_can( 'manage_options' ).
4. Sink: The cache is purged or a purge command is sent.

4. Nonce Acquisition Strategy

If the plugin implements a nonce check (check_ajax_referer) but fails the authorization check, the nonce must be retrieved.

1. Search for Nonce Registration:
   Identify where the nonce is created and localized using:
   grep -rn "wp_create_nonce" .
2. Identify Localization Key:
   Look for wp_localize_script calls. For example:
   wp_localize_script( 'clp-js', 'clp_obj', array( 'nonce' => wp_create_nonce('clp_purge_nonce') ) );
3. Trigger Script Loading:
   Identify if the script loads only on specific pages (e.g., the plugin settings page).
4. Extraction:
   • If the nonce is exposed on the frontend, navigate to the site.
   • If it's only in the admin, and the vulnerability is unauthenticated, the nonce might be missing entirely or the check might be flawed.
   • Note: If check_ajax_referer is present, it usually requires a nonce. If the vulnerability is truly unauthenticated, the nonce check is likely absent or the action is registered via wp_ajax_nopriv_ with a publicly accessible nonce.

5. Exploitation Strategy

The agent should follow these steps:

Step 1: Discovery
Search the plugin files for the vulnerable action:

grep -rn "wp_ajax_nopriv" wp-content/plugins/clp-varnish-cache/
grep -rn "admin_init" wp-content/plugins/clp-varnish-cache/

Identify the callback function and check for current_user_can.

Step 2: Identifying the Purge Action
Examine the callback function. Note the action name (e.g., clp_varnish_purge_all) and any required parameters or nonces.

Step 3: Constructing the Payload
If the action is clp_varnish_purge_all and no nonce is required:

• Method: POST
• URL: http://<target>/wp-admin/admin-ajax.php
• Body (URL Encoded): action=clp_varnish_purge_all

Step 4: Execution
Use the http_request tool to send the purge request.

6. Test Data Setup

1. Install the clp-varnish-cache plugin version 1.0.2.
2. Activate the plugin.
3. (Optional) Configure a dummy Varnish IP in the plugin settings to ensure the code path for purging is fully executed.

7. Expected Results

• Response Code: 200 OK (WordPress AJAX typically returns 200 even on logical failure).
• Response Body: Likely a JSON response like {"success":true} or a string like 1 or Cache Purged.
• Behavior: The plugin logic that connects to Varnish and sends a PURGE or BAN request is triggered.

8. Verification Steps

1. Check Output: Inspect the HTTP response body from the http_request tool.
2. Verify via Logs: If possible, check the WordPress debug log (wp-content/debug.log) for messages indicating the purge function was executed.
3. Code Analysis Verification:
   Confirm the function name and lack of capability check:
   cat wp-content/plugins/clp-varnish-cache/<found_file>.php
   Verify that current_user_can is absent from the identified function.

9. Alternative Approaches

• GET Request: Some plugins handle actions via $_GET. Try:
  GET /wp-admin/admin-ajax.php?action=clp_varnish_purge_all
• Direct Hook: If the action is in admin_init, any request to a file in /wp-admin/ (like admin-ajax.php or admin-post.php) will trigger it if the correct parameters are passed.
• Parameter variations: Check for parameters like purge_all=1 or clp_purge=true that might be checked within an init or admin_init hook.