ACF Extended Critical Bug: When a “Role” Field Turns Registration Into Admin Access

A critical privilege escalation issue was disclosed in Advanced Custom Fields: Extended (ACF Extended), a popular add-on for the Advanced Custom Fields ecosystem with 100,000+ active installs. Under the wrong configuration, an unauthenticated attacker could register a new user (or modify a user via a form action) and set the account’s role to administrator.

The fix is already available: ACF Extended 0.9.2.2 patches the vulnerability. If you run ACF Extended and use its form actions for user creation or user updates, treat this as a “patch now” situation.

What’s the vulnerability, in plain terms?

The issue is an unauthenticated privilege escalation (CVE-2025-14533, CVSS 9.8). In WordPress, “roles” (subscriber, editor, administrator, etc.) control what an account is allowed to do. If an attacker can assign themselves the administrator role, the site is effectively compromised.

According to the advisory, the vulnerable behavior happens in ACF Extended’s user form actions—specifically when a site uses a form action like “Create user” (and potentially “Update user”) and maps submitted form fields into user properties.

Who is actually affected?

Not every site with ACF Extended installed is automatically exploitable. The critical risk requires a specific setup:

• You’re running Advanced Custom Fields: Extended <= 0.9.2.1.
• Your site uses an ACF Extended form action that can insert or update users.
• A user role value is being accepted from the form submission (i.e., the role is mapped to a custom field used by the action).

In other words: the vulnerability becomes exploitable when the form allows a role value to be submitted, and the backend doesn’t strictly limit which roles can be set for unauthenticated users.

How the exploit path works (high level)

ACF Extended includes a form manager that can map submitted fields to WordPress user properties and then create users programmatically. The advisory points to a flow where the plugin constructs a user argument array from submitted values, then calls WordPress core’s wp_insert_user().

That’s not inherently unsafe—if you validate and constrain sensitive properties like roles. The vulnerability exists because the relevant code path did not adequately restrict which roles could be supplied during registration, allowing an attacker to submit administrator as the role when role was mapped.

// Conceptual example of the risky pattern (not the full vendor code)
$args = [];

// Build $args from mapped form fields...
$args['user_login'] = $_POST['user_login'] ?? '';
$args['user_email'] = $_POST['user_email'] ?? '';
$args['user_pass']  = $_POST['user_pass'] ?? '';

// The dangerous part: allowing a submitted role without strict allowlisting.
$args['role'] = $_POST['role'] ?? 'subscriber';

$user_id = wp_insert_user($args);

// Conceptual example of the risky pattern (not the full vendor code)
$args = [];

// Build $args from mapped form fields...
$args['user_login'] = $_POST['user_login'] ?? '';
$args['user_email'] = $_POST['user_email'] ?? '';
$args['user_pass']  = $_POST['user_pass'] ?? '';

// The dangerous part: allowing a submitted role without strict allowlisting.
$args['role'] = $_POST['role'] ?? 'subscriber';

$user_id = wp_insert_user($args);

Once an attacker has an administrator account, they can do what administrators can do: install plugins, edit themes, upload files, change content, add backdoors, or redirect traffic.

Patch status and versions

• Affected: Advanced Custom Fields: Extended <= 0.9.2.1
• Patched: 0.9.2.2
• CVE: CVE-2025-14533
• Severity: Critical (CVSS 9.8)

What to do right now (site owner checklist)

1. Update ACF Extended to 0.9.2.2 immediately.
2. Audit your ACF Extended forms: look specifically for Create user / Update user actions and verify whether role is mapped from user input.
3. If you don’t need user creation via front-end forms, disable or remove those actions and/or unpublish the forms.
4. Review user accounts for unexpected administrators and suspicious new users created around the time the vulnerable version was active.
5. If you use a WAF (Web Application Firewall), ensure rules are current. Wordfence users received protection according to their rollout schedule (Premium/Care/Response earlier; Free later).

A developer takeaway: roles must be server-side allowlisted

This is a textbook example of why security-sensitive fields can’t rely on UI-level restrictions alone. In WordPress, roles and capabilities are high impact. If your code maps arbitrary request data into wp_insert_user() or wp_update_user(), treat the following as mandatory:

• Ignore any submitted role for unauthenticated users unless you have a tight, explicit allowlist.
• Prefer setting a safe default role server-side (often subscriber) and never letting the client override it.
• When building form-to-user mapping features, run a dedicated validation layer for fields like role, user_email, and any metadata that could influence access control.

Disclosure timeline (from the advisory)

• Dec 10, 2025: Vulnerability submitted via Wordfence Bug Bounty Program.
• Dec 11, 2025: Report validated; firewall rule released to Wordfence Premium/Care/Response users; vendor notified via Wordfence Vulnerability Management Portal.
• Dec 14, 2025: Vendor released patched version 0.9.2.2.
• Jan 10, 2026: Wordfence Free users received the firewall rule.

Bottom line

If you run ACF Extended and you’ve ever used its form actions to create or update WordPress users, update to 0.9.2.2 and double-check whether any form accepts a user-submitted role. This bug is only exploitable under certain configurations, but when it is, it’s a straight path to full administrative access.