Proxy & VPN Blocker <= 3.5.8 - Unauthenticated Stored Cross-Site Scripting

This research plan outlines the technical analysis and verification methodology for CVE-2026-57399, a Stored Cross-Site Scripting (XSS) vulnerability in the Proxy & VPN Blocker plugin (versions $\le$ 3.5.8).

1. Vulnerability Summary

The Proxy & VPN Blocker plugin logs metadata from incoming requests (IP addresses, requested URLs, country data) to assist administrators in monitoring blocked traffic. The vulnerability exists because the plugin fails to sanitize or escape this metadata before storing it in the database and subsequently fails to escape the data when rendering it in the admin dashboard via JavaScript. Specifically, the log-ajax.js file handles the display of these logs using jQuery's .append() method, which interprets strings as HTML, allowing for the execution of arbitrary scripts.

2. Attack Vector Analysis

• Vulnerable Endpoint: Any frontend page monitored by the plugin.
• Vulnerable Parameter: The request URI (captured as blocked_url).
• Authentication: Unauthenticated.
• Preconditions: The plugin must be active. The attacker's request must be logged (typically triggered by visiting from a proxy/VPN IP or if the plugin is configured to log specific traffic).

3. Code Flow

The vulnerability involves a path from unauthenticated ingestion to authenticated administrative rendering:

1. Ingestion (PHP): An unauthenticated visitor sends a request. The plugin captures request details. The blocked_url is typically derived from $_SERVER['REQUEST_URI'].
2. Storage (Database): The captured URL is stored in the plugin's log table (e.g., wp_pvb_logs) without sufficient sanitization.
3. Retrieval (AJAX): An administrator accesses the PVB Logs page. assets/js/log-ajax.js calls the loadLogs() function.
4. Backend Fetch: loadLogs() sends a POST request to admin-ajax.php with the action fetch_pvb_logs.
5. Rendering (JS Sink): In the success callback of the AJAX request (within assets/js/log-ajax.js):
   • The script iterates through response.data.
   • It constructs logHtml using the unescaped log.blocked_url.
   • Vulnerable Line:

     logHtml += '<span class="space ipinflux_blocked_on_url" alt="' + log.blocked_url + '">URL: ' + log.blocked_url + '</span>';
     // ...
     $('.log_content').append(logHtml);
     

   • Because log.blocked_url is concatenated directly and then passed to .append(), any HTML/JS in the URL is executed.

4. Nonce Acquisition Strategy

The initial injection (Step 1) is unauthenticated and requires no nonce. To verify the vulnerability via the admin interface, the automated agent must acquire the nonce used by fetch_pvb_logs.

• JavaScript Variable: pvb_action_logs
• Nonce Key: pvb_action_logs.nonce
• Strategy:
  1. Log in as an administrator.
  2. Navigate to the Proxy & VPN Blocker settings page: /wp-admin/admin.php?page=proxy_vpn_blocker_settings.
  3. Extract the nonce from the localized script data using the browser_eval tool:
     browser_eval("window.pvb_action_logs?.nonce")

5. Exploitation Strategy (PoC Methodology)

This methodology uses a benign HTML payload to confirm the vulnerability in an isolated test environment.

1. Trigger Logging:
   Perform an unauthenticated GET request to the site homepage with a benign HTML tag in the query string.

   • Request Tool: http_request
   • URL: https://[TARGET_URL]/?param=<u>xss_verification</u>
   • Note: Ensure the request is logged by the plugin. If logging only occurs on blocks, use a proxy IP or adjust settings to "Block All" during testing.

2. Admin Verification:
   As an administrator, navigate to the PVB Logs interface.

   • Action: Use browser_navigate to /wp-admin/admin.php?page=proxy_vpn_blocker_settings and select the "Logs" tab if necessary.
   • Observation: Observe the log entry for the injected URL.

6. Test Data Setup

• Plugin: Install proxy-vpn-blocker version 3.5.8.
• User: Administrator account for verification.
• Configuration: Ensure the plugin is active. Under "PVB Settings," ensure the "Log" feature is enabled.

7. Expected Results

• The fetch_pvb_logs AJAX response will contain the blocked_url with the <u> tag.
• In the Admin UI, the text xss_verification will appear underlined, confirming that the browser interpreted the injected HTML tag rather than treating it as literal text.

8. Verification Steps (Post-Exploit)

Confirm the payload storage in the database via WP-CLI:

wp db query "SELECT blocked_url FROM wp_pvb_logs ORDER BY id DESC LIMIT 1;"

If the output contains the literal <u> tag, and the admin interface renders it as an HTML element, the vulnerability is confirmed.

9. Alternative Approaches

• Attribute Breakout: Test injection into the alt attribute by using a payload like "><img src=x onerror=console.log('xss_confirmed')>. This verifies if the attribute context is also vulnerable.
• IP Spoofing: If the plugin is configured to trust headers like X-Forwarded-For, the log.ip_address field