The Exploit
An unauthenticated attacker can reset the password of any WordPress user—including administrators—by sending a password reset request with an empty or tampered token parameter. No prior account compromise is required.
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.wordpress.local
Content-Type: application/x-www-form-urlencoded
action=rm_reset_password&token_val=&user_login=administrator
The server responds with a success message and updates the administrator's password to a value controlled by the attacker. The attacker then logs in as administrator with the new password. A valid password reset token is never validated; the empty string is accepted as-is and processed through the password reset flow, bypassing the intended security gate.
What the Patch Did
Before
} else {
$token= $request->req['token_val'];
$users= get_users(array('meta_key' => 'rm_pass_token', 'meta_value' =>$token));
if(!empty($users)){
After
} else {
$token = $request->req['token_val'];
if(empty($token)) {
$data->invalid_copy_token = 1;
} else {
$users = get_users(array('meta_key' => 'rm_pass_token', 'meta_value' => $token));
if(!empty($users)){
The patch adds an explicit if(empty($token)) guard before the database query. This check rejects any empty, null, or whitespace-only token values and sets an error flag (invalid_copy_token = 1), halting password reset processing. The vulnerable code never performed this validation, allowing an empty token_val parameter to be passed directly to get_users() where it would match against the stored password reset tokens in the database in unexpected ways or proceed through logic that should have been gated.
Root Cause
CWE-20: Improper Input Validation. The token_val parameter flows directly from the AJAX request ($request->req['token_val']) into a get_users() database query without validating that it contains a non-empty value. This is a missing validation gate at the entry point of the password reset controller. The attacker-controlled value crosses a trust boundary (from untrusted HTTP input into security-sensitive password reset logic) unchecked. The code assumes that if get_users() returns results, the token must be valid, but an empty token can trigger unintended query behavior or match entries that should never be accessible without a proper token.
Why It Works
The load-bearing line is if(empty($token)). Without it, the vulnerable code proceeds unconditionally to query the user database, and the assumption that a valid token was provided is never enforced. Removing the error condition alone would not fully fix the bug if the rest of the function still accepted empty inputs downstream; the engineer had to block the entire reset flow (} else { ... }) to ensure that an empty token cannot reach password-change code at all. The defensive structure—checking emptiness first, setting an error flag, then wrapping the rest in an else clause—ensures that the attack surface is closed at the earliest possible point. This layered approach (validation + conditional execution) is more resilient than a single defensive statement later in the function.
Hardening Checklist
- Validate all password reset tokens with
wp_verify_nonce()or a HMAC-verified token scheme. Do not rely on database queries alone to establish token validity; cryptographic verification must occur before any password update. - Always check
!empty()orisset()on security-critical request parameters before use. Gate password reset, account recovery, and privilege escalation endpoints with explicit input presence checks immediately after unpacking$_REQUESTor$_POST. - Wrap sensitive logic in a capability check using
current_user_can()as a secondary gate. Even if a token validation is bypassed, a secondarycurrent_user_can('manage_options')check on account updates for admin users adds a second line of defense. - Use
wp_generate_password()and store tokens with a time-to-live (TTL) thatget_user_meta()can enforce. Ensure reset tokens expire; query tokens with both the token value and an expiry timestamp. - Log all password reset attempts and successful password changes via
wp_insert_log()or similar. Detect and alert on bulk or anomalous password resets that may indicate mass account takeover.
References
- https://nvd.nist.gov/vuln/detail/CVE-2024-10508