Debugger & Troubleshooter <= 1.3.2 - Unauthenticated Privilege Escalation to Administrator via Cookie Manipulation

This research plan outlines the steps to exploit CVE-2026-5130, a critical unauthenticated privilege escalation vulnerability in the Debugger & Troubleshooter plugin (<= 1.3.2).

1. Vulnerability Summary

The "Debugger & Troubleshooter" plugin includes a "User Role Simulator" feature intended to allow administrators to view the site as different users for testing purposes. The vulnerability stems from a lack of authorization and integrity checks when processing the simulation state. The plugin reads a user ID directly from the wp_debug_troubleshoot_simulate_user cookie and uses it to override the current WordPress user via the determine_current_user filter.

Because the cookie is not cryptographically signed, validated against a server-side session, or restricted to already-authenticated administrators, an unauthenticated attacker can simply provide this cookie with the ID of an administrator (typically 1) to gain full administrative access to the site.

2. Attack Vector Analysis

• Endpoint: Any WordPress URL (frontend or backend). The vulnerability is triggered during the WordPress bootstrap process.
• Vulnerable Parameter: The HTTP Cookie header.
• Cookie Name: wp_debug_troubleshoot_simulate_user (defined by the constant SIMULATE_USER_COOKIE).
• Authentication: Unauthenticated. No valid session or login is required.
• Preconditions: The plugin must be active.

3. Code Flow

1. Entry Point: In debug-troubleshooter.php, the Debug_Troubleshooter class constructor registers the init_user_simulation method on the plugins_loaded hook at priority 0.

   add_action('plugins_loaded', array($this, 'init_user_simulation'), 0);
   

2. Cookie Processing: Inside init_user_simulation() (inferred from the patch description and constants), the code checks for the existence of the wp_debug_troubleshoot_simulate_user cookie.
3. Filter Registration: If the cookie is present, the plugin registers a filter on determine_current_user.

   add_filter('determine_current_user', array($this, 'filter_determine_current_user'));
   

4. Sink (Identity Theft): The callback filter_determine_current_user (inferred) retrieves the value from the cookie and returns it as the current user ID.

   public function filter_determine_current_user($user_id) {
       if (isset($_COOKIE['wp_debug_troubleshoot_simulate_user'])) {
           return (int) $_COOKIE['wp_debug_troubleshoot_simulate_user'];
       }
       return $user_id;
   }
   

5. Execution Context: Because plugins_loaded priority 0 runs extremely early, this filter is in place before WordPress core attempts to authenticate the user, effectively bypassing the entire authentication system.

4. Nonce Acquisition Strategy

No nonce is required.
The vulnerability resides in the way the plugin handles every incoming request based on cookies. It does not require interacting with the AJAX handlers (wp_ajax_debug_troubleshoot_toggle_simulate_user) which do implement nonce checks. By manually setting the cookie, the attacker bypasses the "official" UI toggle and its associated security checks.

5. Exploitation Strategy

The goal is to access the WordPress Admin Dashboard as the primary administrator.

1. Step 1: Identify Target User ID: In standard WordPress installations, the first administrator created has ID 1.
2. Step 2: Forge Request: Use the http_request tool to send a GET request to /wp-admin/ with the malicious cookie.
3. Step 3: Verification of Escalation: Check the response body for indicators of administrative access (e.g., the presence of the "Plugins" menu or the string "Dashboard").

Specific Payload

• Method: GET
• URL: /wp-admin/
• Headers:

  Cookie: wp_debug_troubleshoot_simulate_user=1
  

6. Test Data Setup

1. Target User: Ensure a user with ID 1 exists and is an administrator (default behavior).
2. Plugin Activation: The Debugger & Troubleshooter plugin (version 1.3.2) must be installed and activated.
3. Environment: No specific settings are required within the plugin, as the vulnerable code runs automatically on every page load if the cookie is detected.

7. Expected Results

• Response Code: 200 OK (instead of a redirect to wp-login.php).
• Response Content: The HTML source of the WordPress Dashboard.
• Administrative Capabilities: Elements like <li id="menu-plugins"> or <div id="wpadminbar"> will be present in the response, confirming that the site perceives the unauthenticated requester as the user with ID 1.

8. Verification Steps

After the http_request, confirm the vulnerability using the execution agent:

1. Check for Admin Elements:

   // Run via browser_eval on the /wp-admin/ page
   !!document.querySelector('#menu-settings') && !!document.querySelector('#menu-plugins')
   

2. Verify Identity via WP-CLI:
   Since the exploit is session-based via cookie, use the cookie in an http_request to an AJAX action that returns user info, or verify that the admin dashboard loads successfully.

9. Alternative Approaches

If ID 1 is not the administrator:

1. Enumerate User IDs: Iterate through common IDs (1, 2, 3, etc.) in the cookie until the /wp-admin/ request returns a 200 OK containing admin strings.
2. Examine Public Data: Visit /wp-json/wp/v2/users to identify available user IDs and their roles (if the REST API is public).
3. Bypass Login Page: If /wp-admin/ redirects to /wp-admin/index.php, ensure the cookie is passed to the redirected URL as well.