Exploitation Research Plan: CVE-2026-6456 (Account Switcher)

1. Vulnerability Summary

The Account Switcher plugin (<= 1.0.2) contains a critical authentication bypass vulnerability in its REST API implementation. The rememberLogin endpoint, located in app/RestAPI.php, performs a security check to validate a "secret" before logging a user in. However, it uses a loose comparison (!=) instead of a strict comparison (!==) and fails to verify that the secret is actually set.

Because get_user_meta( $user_id, 'asSecret', true ) returns an empty string ('') if the meta key does not exist (e.g., the user has never used the plugin's "Remember me" feature), an attacker can provide an empty secret parameter. The logic '' != '' evaluates to false, causing the validation to pass. Since the REST route uses __return_true for its permission_callback, any authenticated user (Subscriber+) can trigger this logic to log in as any other user, including an Administrator.

2. Attack Vector Analysis

• Endpoint: REST API Route (likely wp-json/account-switcher/v1/remember-login - inferred from plugin slug and method name).
• Method: POST (standard for authentication actions).
• Parameters:
  • id or user_id: The ID of the target user (typically 1 for the primary Administrator).
  • secret: An empty string.
• Authentication: Requires Subscriber-level privileges or higher to access the REST API with a valid nonce.
• Preconditions: The target Administrator must not have used the "Remember me" feature (ensuring asSecret meta is empty/missing).

3. Code Flow

1. Entry Point: The plugin registers REST routes during rest_api_init.
2. Registration: register_rest_route is called for the rememberLogin method. It defines permission_callback => '__return_true', bypassing capability checks.
3. Handler Execution: app/RestAPI.php:111 (approx.) executes the handler for the route.
4. Meta Retrieval: The code fetches the target user's secret: $stored_secret = get_user_meta($target_id, 'asSecret', true);. If the user never used the feature, $stored_secret is ''.
5. Vulnerable Comparison:

   // Inferred logic at line 111
   if ( $request_secret != $stored_secret ) {
       return new WP_Error( ... );
   }
   

6. Bypass: If $request_secret is '' and $stored_secret is '', the check '' != '' is false.
7. Sink: The code proceeds to call wp_set_auth_cookie( $target_id ).

4. Nonce Acquisition Strategy

While the permission_callback is __return_true, WordPress REST API requests made with cookie authentication still require a _wpnonce (the wp_rest nonce) to prevent CSRF and validate the session.

1. Login as Attacker: Log in to the WordPress site as a Subscriber.
2. Navigate to Dashboard: Access /wp-admin/index.php.
3. Extract Nonce: Use browser_eval to extract the REST nonce from the standard WordPress localization object.
   • Action: browser_eval("wpApiSettings.nonce")
   • Alternative: If wpApiSettings is not available, find the nonce in the script block for wp-api-request or wp-util.

5. Exploitation Strategy

1. Setup Identities:
   • Target: Administrator (ID 1).
   • Attacker: Subscriber (ID 2).
2. Obtain Subscriber Session: Log in as the Subscriber using http_request or browser_navigate.
3. Fetch REST Nonce: Execute browser_eval("wpApiSettings.nonce") while on an admin page as the Subscriber.
4. Perform Account Switch: Send a POST request to the vulnerable endpoint.
   • URL: /wp-json/account-switcher/v1/remember-login (Verify route via wp rest route list if needed).
   • Headers:
     • X-WP-Nonce: [EXTRACTED_NONCE]
     • Content-Type: application/json
   • Body: {"id": 1, "secret": ""}
5. Capture Cookies: The response will contain Set-Cookie headers for the Administrator user session.
6. Verify Elevation: Use the captured cookies to make a request to /wp-admin/ and verify the identity is now the Administrator.

6. Test Data Setup

1. Create Admin: Ensure a user with Administrator role exists (usually ID 1). Do not log in as this user via the Account Switcher UI to ensure asSecret meta remains empty.
2. Create Subscriber:

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

3. Verify Meta State: Confirm the target admin lacks the meta key:

   wp usermeta get 1 asSecret
   # Should return an error or empty result
   

7. Expected Results

• Successful comparison bypass: The server returns a 200 OK or 302 Found response.
• Cookie Issuance: The Set-Cookie header in the response will contain a new wordpress_logged_in_... cookie corresponding to the Administrator (User ID 1).
• Privilege Escalation: Subsequent requests using the new cookie will have full Administrative access.

8. Verification Steps

1. Check Current User via CLI: After the HTTP request, verify who the attacker's session currently represents (if testing via browser) or check the session token generated in the database.
2. Verify Cookie Identity: Use the http_request tool with the new cookies to call:
   • URL: /wp-json/wp/v2/users/me
   • Result: Should show id: 1 and roles: ["administrator"].
3. UI Verification: Navigate to /wp-admin/plugins.php using the captured cookies. If the page loads without a permission error, escalation is confirmed.

9. Alternative Approaches

• Targeting via Username: If the endpoint accepts a username instead of an ID, try {"username": "admin", "secret": ""}.
• Query Parameters: If the JSON body is not processed, try sending the payload as URL-encoded parameters in the POST body or as GET query parameters (though REST routes usually favor body params for POST).
• Identifying the Route: If account-switcher/v1/remember-login is incorrect, search the plugin for register_rest_route to find the exact namespace and path:

  grep -r "register_rest_route" wp-content/plugins/account-switcher/