CVE-2025-14533: ACF Extended Privilege Escalation (100K Sites)

Overview

• CVE: CVE-2025-14533
• Plugin: Advanced Custom Fields: Extended (ACFE)
• Affected Versions: All versions up to and including 0.9.2.1
• Patched Version: 0.9.2.2
• CVSS: 9.8 (Critical)
• Authentication: None required (unauthenticated attack)
• Type: Privilege Escalation (Missing Role Restriction on User Registration)
• Active Installs: ~100,000

A critical vulnerability was discovered in ACF Extended, a widely used companion plugin for Advanced Custom Fields (ACF). The flaw allows an unauthenticated attacker to create an administrator-level account on an affected WordPress site. A public proof-of-concept exploit is available on GitHub, making active exploitation highly likely.

Privilege escalation vulnerabilities of this kind are among the most severe in the WordPress ecosystem. Once an attacker gains administrator access, the entire site is effectively under their control: backdoors can be planted, content defaced, user data exfiltrated, and the site weaponized against visitors or other targets.

What Happened

ACF Extended significantly expands the capabilities of the ACF plugin, including the ability to build front-end registration forms that create WordPress user accounts. Site administrators can use these forms to collect custom data during user sign-up.

The vulnerability existed in the insert_user function. When this function processed form submissions to create new users, it failed to enforce any restriction on which WordPress role could be assigned to the new account.

In a standard WordPress registration flow, new users are assigned a low-privilege role such as subscriber. However, the insert_user function in ACFE accepted the role field from the submitted form data directly, without validation against an allowlist or a fixed safe default.

This means an attacker could craft a registration request specifying role=administrator and WordPress core would honor it, creating a fully privileged account.

One conditional requirement applies: the target site must have configured a front-end ACFE form that maps the form's role field to the WordPress user role field. This configuration is used in specific scenarios, such as membership sites that let users select their own role. Not every site running ACF Extended is vulnerable, but those with this configuration enabled are fully exposed.

How the Attack Works

The attack requires only a single HTTP request. After identifying a page hosting an ACF Extended front-end registration form, the attacker submits a crafted payload:

POST /targeted-registration-page/ HTTP/1.1
Host: target-site.com
Content-Type: application/x-www-form-urlencoded

acf[field_user_login]=attacker&acf[field_user_email]=attacker%40example.com&acf[field_user_password]=P%40ssw0rd123&acf[field_user_role]=administrator&_acf_nonce=...

The insert_user function receives the role value from the form payload without validating it against any allowed range. It passes the value directly to WordPress's wp_insert_user(), which faithfully creates a user with the administrator role.

The root cause is a missing server-side validation step. Secure implementations of similar features enforce a server-side allowlist of permissible roles, or unconditionally cap the role to subscriber (or whatever minimum role the site requires), regardless of what the form submits. ACFE 0.9.2.1 did neither.

Public PoC scripts on GitHub automate both the discovery of vulnerable form pages and the account creation step. Automated scanning of WordPress installations for ACF Extended and subsequent exploitation attempts have been observed in the wild.

Real-World Impact

Of the approximately 100,000 active installations, sites that use ACFE front-end registration forms with the role field mapped to the WordPress user role field are the directly vulnerable population. While this represents a subset of all installations, the consequences when exploitation succeeds are total.

An attacker with administrator access can:

• Upload PHP backdoor files via the media library or theme editor, maintaining persistent access even after the ACFE plugin is patched
• Modify or delete all site content
• Harvest registered user data including email addresses and hashed passwords
• Embed malware to compromise site visitors (watering hole attacks)
• Alter WordPress core settings to create additional backdoor accounts
• Use the site as infrastructure for attacks against other targets

A particularly dangerous aspect of this vulnerability is how cleanly it blends in. The attack uses the normal user registration mechanism, so web server logs will show ordinary POST requests with no obvious indication of compromise.

Fix and Lessons

Fix: Update ACF Extended to version 0.9.2.2 or later. The patched version restricts the insert_user function so that the role assigned to a newly registered user is validated against an administrator-defined allowlist, preventing arbitrary role assignment from form input.

Sites requiring immediate action:

1. Running ACF Extended version 0.9.2.1 or earlier
2. With a front-end user registration form active
3. Where the form's role field is mapped to the WordPress user role field

If all three conditions apply, treat this as a critical incident response situation. Immediately audit the WordPress user list for any unexpected Administrator accounts created after the plugin was installed. If suspicious accounts are found, revoke them and investigate for signs of further compromise such as new files in wp-content/uploads/ or modified theme files.

Development lessons:

1. Never trust client-supplied privilege data: Any field that influences the permissions of a newly created entity must be validated server-side against a strict allowlist. The client cannot be the authority on what role it deserves.
2. Principle of least privilege by default: Registration flows should default to assigning the minimum viable role. Elevation to higher roles should require a deliberate, separate action by an existing administrator.
3. Enumerate your inputs: Values that map to discrete options (roles, statuses, capabilities) should be defined as an explicit set in code. Anything outside that set should be rejected outright, not silently accepted or coerced.
4. Conditional attack surface is still attack surface: The fact that exploitation requires a specific configuration does not make a vulnerability low-severity. CVSS 9.8 was assigned because when the conditions are met, the impact is complete.

Detection with Nyambush

Nyambush scans WordPress sites and detects installed plugins along with their versions. When ACF Extended version 0.9.2.1 or earlier is detected, Nyambush flags it as CVE-2025-14533 and reports it as a critical finding.

Scheduled scans ensure that newly discovered vulnerabilities are surfaced promptly. With a public PoC already available for this vulnerability, the window between disclosure and active exploitation is measured in hours to days, not weeks. Combining automated periodic scans with a disciplined patching process is the most reliable way to stay ahead of attackers targeting known vulnerabilities.