The Branda plugin for WordPress is vulnerable to privilege escalation via account takeover in all versions up to, and including, 3.4.24. This is due to the plugin not properly validating a user's identity prior to updating their password. This makes it possible for unauthenticated attackers to change arbitrary user's passwords, including administrators, and leverage that to gain access to their account.
Unauthenticated attackers can exploit a critical vulnerability in the Branda WordPress plugin to takeover any user account, including administrators, by changing their passwords. This flaw allows for complete site compromise and potential data breaches, posing a significant risk to affected websites.
Step 1: Target Identification: The attacker identifies a WordPress website using the vulnerable Branda plugin (versions up to and including 3.4.24).
Step 2: User Enumeration (Optional): The attacker may attempt to enumerate usernames, although this is not strictly necessary. The attacker can target any user account.
Step 3: Crafting the Malicious Request: The attacker crafts a malicious HTTP request to the Branda plugin's password update functionality. This request includes the target user's username or user ID and the attacker's desired new password.
Step 4: Request Submission: The attacker sends the crafted request to the vulnerable WordPress site.
Step 5: Password Update: Due to the lack of proper authentication, the plugin processes the request and updates the target user's password to the attacker-specified value.
Step 6: Account Takeover: The attacker uses the newly set password to log in to the target user's account, gaining control of the account and potentially the entire website.
The vulnerability stems from a lack of proper identity validation within the Branda plugin when handling password update requests. Specifically, the plugin fails to verify the authenticity of the user making the password change request. This allows an attacker to craft a malicious request, potentially bypassing authentication mechanisms and directly modifying the password of any user account. The root cause is likely a missing or insufficient check on the user's session or authentication token before processing the password update logic. This could be due to a missing is_user_logged_in() check or a failure to validate the provided user ID against the current session.