ANALYSIS · 8b0494b8· FINISHED 2026-06-13 · PATCHDIFF

acf-extended0.9.2.1 → 0.9.2.2✓ COMPLETED

Files24

Vulnerable14

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

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 24 CVE 2 Vuln 14

SORT

2 files · page 1/1

includes/fields/field-user-roles.php

AI: 1 vulnerabilities

CWE-20: Improper Input Validation CVE-2025-14533

#%!d(float64=018)

includes/modules/form/module-form-action-user.php

AI: 3 vulnerabilities

CWE-269: Improper Privilege ManagementCWE-209: Generation of Error Message Containing Sensitive InformationCWE-20: Improper Input Validation CVE-2025-14533

#%!d(float64=020)

1–2 of 2

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2025-14533

Security writeup for CVE-2025-14533

✓ 2 FILES

## The Exploit

Any unauthenticated user can register on an affected WordPress site running ACF Extended ≤0.9.2.1 with a user registration form that maps the `role` field to a custom field; the attacker submits `administrator` as the role value and gains full site access.

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

action=acfe_form_submit&form_id=123&fields[user_email]=attacker@example.com&fields[user_login]=attacker&fields[user_pass]=Password123&fields[role]=administrator
```

The response contains a success message and a new user account with the `administrator` role appears in the WordPress user table. The attacker can immediately navigate to `/wp-admin/` and modify site content, install plugins, or create additional backdoor accounts.

## What the Patch Did

**Before:**

```php
// check built-in validation
if(empty($action['validation'])){
    return false;
}

// apply tags
$action = $this->setup_action($action, $form);
```

**After:**

```php
// security measure
// check 'promote_users' capability for insert/update administrator role
if($action['type'] === 'insert_user' || $action['type'] === 'update_user'){
    
    // get role as array
    $role = acf_get_array($action['save']['role']);
    
    // check capability
    if((in_array('administrator', $role, true) || in_array('super_admin', $role, true)) && !current_user_can('promote_users')){
        
        // filters
        $validate = true;
        $validate = apply_filters("acfe/form/validate_user_admin_role", $validate, $form, $action);
        
        // should validate
        if($validate){
            return acfe_add_validation_error('', $errors['generic']);
        }
        
    }
    
}
```

The patch added a capability check using `current_user_can('promote_users')` that explicitly prevents unauthenticated and unprivileged users from assigning the `administrator` or `super_admin` roles during user creation or modification. This control is invoked *before* the generic validation logic runs, making it load-bearing in the privilege escalation defence.

Additionally, a companion validation method was added to `field-user-roles.php` that validates submitted role values against the declared field choices using `array_diff()`, preventing arbitrary role injection at the form field level.

## Root Cause

**CWE-269: Improper Access Control / CWE-20: Improper Input Validation**

The `insert_user` and `update_user` actions in the form module accepted a `role` parameter from the request without verifying the caller's capability to assign that role. When a front-end registration form mapped the `role` field to a custom ACF field, an unauthenticated POST to `/wp-admin/admin-ajax.php` with `action=acfe_form_submit` would pass the attacker-supplied `role=administrator` value directly into the WordPress user creation function. The dataflow crosses the authentication boundary unchecked: the request parameter `fields[role]` travels through `$action['save']['role']` into `wp_insert_user()` with no intermediate capability check. WordPress provides `current_user_can('promote_users')` to gate this operation; the original code never called it.

## Why It Works

The single load-bearing line is:

```php
if((in_array('administrator', $role, true) || in_array('super_admin', $role, true)) && !current_user_can('promote_users')){
```

If this condition were removed, an attacker could still inject any role value into the user object. The remaining lines (filter hook, validation error return) provide extensibility and consistent error handling — they are belt-and-suspenders defence-in-depth — but without the `current_user_can()` check itself, there is no gate at all. The `array_diff()` validation in the field-level method is a secondary control that raises the bar by also checking against declared field choices, but on a registration form where the developer intends to allow a user to self-select a role (a rare but real scenario), that field-level check might be disabled via `allow_custom`. The capability check in the action handler cannot be disabled without code change, making it the true anchor.

The engineer added the field-level validation because it follows the principle of defense-in-depth and catches arbitrary role injection at the form layer even if the action-level check is somehow bypassed. The filter hook ensures custom hardening logic can run; it is not required for security but improves enterprise compatibility.

## Hardening Checklist

- **Always call `current_user_can()` before assigning WordPress roles or capabilities.** In user creation/update handlers, check the *current* user's `promote_users` capability against the *submitted* role(s) before passing them to `wp_insert_user()` or `wp_update_user()`. Do not assume the form will be "private" or that only admins will submit it.

- **Validate submitted choice values against declared field options using a whitelist.** Implement a validation method like the one in the patch that calls `array_diff($submitted_values, $allowed_choices)` and returns false if the diff is non-empty, unless the field explicitly allows custom values via a flag like `allow_custom`.

- **Use WordPress's built-in data access functions, not direct globals.** Replace manual array access like `$_POST['role']` with `acf_get_array()` or similar wrapper functions that are testable, loggable, and easier to intercept with hooks.

- **Log privilege-escalation attempts.** When the capability check fails, call `error_log()` or a proper logging function with the user ID, requested role, and form ID. This surfaces attacks in security monitoring.

- **Provide extensibility without disabling core security.** Use `apply_filters()` to let integrators add logic, but ensure the filter result is checked *after* the core control, not instead of it, as shown in the patch.

## References

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

CVE CVE-2025-14533

PRODUCT acf-extended

AFFECTED ≤ 0.9.2.1

FIXED IN 0.9.2.2

STATUS Generated

Security writeup · CVE-2025-14533

Source files · 2

includes/fields/field-user-roles.php Linked

includes/modules/form/module-form-action-user.php Linked

↗ NVD