ANALYSIS · 560349ec· FINISHED 2026-06-13 · PATCHDIFF

user-registration5.1.2 → 5.1.3✓ COMPLETED

Files506

Vulnerable37

True positives0

CVE matched2

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

CVE-2026-1492

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 506 CVE 2 Vuln 37

SORT

2 files · page 1/1

includes/RestApi/controllers/version1/class-ur-getting-started.php

No vulnerability

CVE-2026-1492

#%!d(float64=011)

modules/membership/includes/Admin/Services/MembersService.php

AI: 3 vulnerabilities

CWE-639: Authorization Bypass Through User-Controlled KeyCWE-20: Improper Input ValidationCWE-287: Improper Authentication CVE-2026-1492

#%!d(float64=033)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-1492

Security writeup for CVE-2026-1492

✓ 2 FILES

## The Exploit

An unauthenticated attacker can create a WordPress administrator account by sending a single HTTP request to the user registration endpoint, supplying an arbitrary `role` parameter in the request body.

```http
POST /wp-json/ur/v1/users HTTP/1.1
Host: target.wordpress.local
Content-Type: application/json

{
  "user_email": "attacker@evil.com",
  "user_login": "admin_attacker",
  "user_password": "Password123!",
  "membership": "1",
  "role": "administrator"
}
```

The response contains HTTP 201 Created with a user object. The attacker then logs in with the supplied credentials and gains full WordPress administrative control. No existing authentication, nonce, or capability check blocks the role assignment during registration.

## What the Patch Did

**Before:**
```php
public function prepare_members_data( $data ) {
    $response         = array();
    $response['role'] = isset( $data['role'] ) ? sanitize_text_field( $data['role'] ) : 'subscriber';
```

**After:**
```php
public function prepare_members_data( $data, $context = 'admin' ) {
    if ( 'frontend' === $context ) {
        $membership_detail  = $this->membership_repository->get_single_membership_by_ID( absint( $data['membership'] ) );
        $data['role']       = isset( $membership_detail['role'] ) ? sanitize_text_field( $data['role'] ) : 'subscriber';
    }
    
    $response         = array();
    $response['role'] = isset( $data['role'] ) ? sanitize_text_field( $data['role'] ) : 'subscriber';
```

The patch introduces a `$context` parameter and adds logic to enforce role assignment from the membership repository when the function is called from the frontend. Instead of blindly accepting the `role` value from user input (`$data['role']`), the code now retrieves the role from the membership configuration stored in the database and uses that as the authoritative source. `sanitize_text_field()` is preserved to ensure the retrieved role string is safe, but the source of truth has shifted from untrusted user input to server-side configuration.

## Root Cause

**CWE-639: Authorization Bypass Through User-Controlled Key** and **CWE-20: Improper Input Validation**.

The `prepare_members_data()` function accepted the `role` key directly from the request body without validating that the caller (frontend user during registration) had permission to assign that role. The dataflow: a POST request to `/wp-json/ur/v1/users` supplies a JSON body containing `role: "administrator"`. This request body is parsed and passed as the `$data` array to `prepare_members_data()`. The function reads `$data['role']` and uses `sanitize_text_field()` to escape it for output safety — but `sanitize_text_field()` does not validate that the role string is an allowed role or that the requester can assign it. The role value crosses the trust boundary from untrusted user input directly into the user creation logic without an allowlist check or context-aware authorization rule.

## Why It Works

The load-bearing line is the context check: `if ( 'frontend' === $context )`. Removing this line would preserve the vulnerability because the code would still accept `$data['role']` from user input on the next line. The auxiliary changes—retrieving `$membership_detail` from the repository and assigning `$data['role']` from that object instead of the request—implement the actual allowlist enforcement. The engineer added the repository lookup because the membership entity already contains the authorized role for that membership tier; reusing that value ensures the registration flow respects the membership configuration rather than letting users self-assign roles. The `absint()` call on the membership ID prevents SQL injection in the repository query. The context parameter is the guard that prevents this allowlist logic from running on admin requests, where the role *should* come from the admin's input (subject to separate capability checks elsewhere in the stack).

## Root Cause (Continued)

The root cause is lack of an authorization boundary. The REST endpoint that calls `prepare_members_data()` did not enforce a check like `current_user_can( 'manage_options' )` for admin-only roles, nor did it enforce a per-endpoint rule: "frontend callers must use the role defined in the membership product; admin callers may override." Instead, both code paths were conflated in a single function that blindly trusted `$data['role']`.

## Hardening Checklist

- **Add a role allowlist in REST endpoints.** Before accepting a `role` parameter from a frontend request, explicitly check that the role exists in `get_editable_roles()` and that the current user has permission to assign it (use `wp_roles()->is_role()` for existence and `current_user_can()` for authorization). Reject any role not in the allowlist with a 403 Forbidden response.

- **Use a context parameter to separate admin and frontend flows.** Always pass a `$context` flag to functions that handle user input differently based on the caller's privilege level. Use strict equality checks (`===`) against whitelisted strings ('admin', 'frontend') rather than trusting function defaults.

- **Retrieve sensitive fields from the database, not from user input.** For fields like role that should be tied to a server-side entity (membership tier, subscription plan), always load the authoritative value from the database and validate user input against it. Use `$wpdb->prepare()` or ORM methods to prevent SQL injection.

- **Validate required parameters with `! empty()` not `isset()`** when the parameter must have a non-null, non-empty value. Use `isset()` only when checking for the presence of an optional key.

- **Apply `wp_verify_nonce()` to all form submissions and REST endpoints that modify user state.** Even if the endpoint is publicly accessible, a nonce check prevents CSRF attacks and signals that state-changing operations must originate from the same site.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2026-1492

CVE CVE-2026-1492

PRODUCT user-registration

AFFECTED ≤ 5.1.2

FIXED IN 5.1.3

STATUS Generated

Security writeup · CVE-2026-1492

Source files · 2

includes/RestApi/controllers/version1/class-ur-getting-started.php Linked

modules/membership/includes/Admin/Services/MembersService.php Linked

↗ NVD