CVE-2026-12526: Advanced Custom Fields: Extended < 0.9.2.7 - Unauthenticated Administrator Account Takeover via Front-End User Update Action
The Advanced Custom Fields: Extended WordPress plugin before 0.9.2.7 does not verify that the requester is authorized to edit the targeted user account in the update-user action of its front-end Forms module; it only checks a capability when the submitted role is administrator or superadmin. On a site that exposes a publicly reachable front-end form whose user-update action targets an existing administrator (a fixed target, or one mapped to a visitor-submitted field) and maps the password to a visitor-submitted field, an unauthenticated visitor can overwrite that administrator's password and take over the account. The default target is the submitting user, so exploitation depends on the form being configured to target another account.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Advanced Custom Fields: Extended (WordPress plugin)to a version that resolves this vulnerability.Fixed in 0.9.2.7 - Configuration
Reconfigure the plugin’s front-end form(s) so the update-user action does not overwrite a different, existing administrator account (e.g., remove/disable any configuration that sets a fixed target user or maps the target user to a visitor-submitted field).
Advanced Custom Fields: Extended (WordPress plugin) - front-end Forms module user-update action target and role handling = Ensure update-user action cannot target another user account (including fixed/visitor-submitted targets) unless the requester is authorized - Compensating control
Remove or restrict public access to any exposed front-end forms that perform user-update actions, until the plugin is upgraded to 0.9.2.7.
Event History
Frequently Asked Questions
Which deployments are realistically exposed to unauthenticated takeover?
Exposure requires a publicly reachable front-end Forms user-update form that targets an existing administrator account, either as a fixed target or through a visitor-controlled field, and accepts the password from a visitor-submitted field. Forms using the default target of the submitting user are not exploitable in this way unless they have been configured to target another account.
What must an attacker be able to do to exploit this issue?
An attacker only needs unauthenticated access to the affected front-end form and the ability to submit a password value through the field mapped to the target account's password. The form must be configured to update an administrator account rather than the submitting user.
How can I identify potentially affected forms?
Review publicly reachable front-end Forms user-update actions for configurations that select an existing administrator as the update target, including targets derived from visitor-submitted fields. Also identify forms where a visitor-controlled field is mapped to the password field for that target account.
What configuration change can reduce risk if updating is not immediately possible?
Remove public access to affected front-end user-update forms, or change them so they do not target another user account and do not map passwords from visitor-submitted fields. In particular, avoid fixed administrator targets and visitor-controlled target-user mappings.