ANALYSIS · ca75590c· FINISHED 2026-06-13 · PATCHDIFF

custom-registration-form-builder-with-submission-manager6.0.2.6 → 6.0.2.7✓ COMPLETED

Files5

Vulnerable4

True positives0

CVE matched1

1 CVE article ready PatchLeaks generated full security writeups for the matched CVEs · one per CVE, with affected files linked

CVE-2024-10508

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 5 CVE 1 Vuln 4

SORT

1 files · page 1/1

public/controllers/class_rm_login_controller.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2024-10508

#%!d(float64=004)

1–1 of 1

⌖

Select a file from the list to inspect its diff and AI analysis.

↑ ↓ to navigate

CVES 1

CVE-2024-10508

Security writeup for CVE-2024-10508

✓ 1 FILE

## 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.

```http
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**

```php
} else {
    $token= $request->req['token_val'];
    $users= get_users(array('meta_key' => 'rm_pass_token', 'meta_value' =>$token));
    if(!empty($users)){
```

**After**

```php
} 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()` or `isset()` on security-critical request parameters before use.** Gate password reset, account recovery, and privilege escalation endpoints with explicit input presence checks immediately after unpacking `$_REQUEST` or `$_POST`.
- **Wrap sensitive logic in a capability check using `current_user_can()` as a secondary gate.** Even if a token validation is bypassed, a secondary `current_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) that `get_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

CVE CVE-2024-10508

PRODUCT custom-registration-form-builder-with-submission-manager

AFFECTED ≤ 6.0.2.6

FIXED IN 6.0.2.7

STATUS Generated

Security writeup · CVE-2024-10508

Source files · 1

public/controllers/class_rm_login_controller.php Linked

↗ NVD