ACF Extended CVE-2026-94267: Front-End Form Takeover Flaws

If you use Advanced Custom Fields: Extended, update it to 0.9.2.8 today, free or PRO. Then check whether any of your front-end forms let visitors choose what they’re editing. On October 22 and 23, five vulnerabilities in ACF Extended’s Forms module were published together. The worst lets an anonymous visitor rewrite posts on your site, including the ones that hold your field definitions, and turn that into running code on the server. Two more let a visitor take over user accounts, up to and including the administrator. None of them is being exploited yet, and most sites aren’t exposed. This post is about telling which kind of site you have.

At a glance

CVEs	CVE-2026-94267, CVE-2026-94268, CVE-2026-94262, CVE-2026-94263, CVE-2026-112311
Plugin	Advanced Custom Fields: Extended, free and PRO (more than 100,000 active installs of the free version)
Type	Unauthenticated remote code execution, account takeover, shortcode execution and file deletion, all in the front-end Forms module
Severity	Up to CVSS 9.0 in the official record (Wordfence rates the worst 9.8). The official scores are lower because most of these need a specific form setup
Affected	0.9.2.7 and earlier (the shortcode bug: 0.9.2.4 to 0.9.2.7)
Fixed	0.9.2.8, released October 19, 2026, for both free and PRO
Status	No exploitation reported. CISA’s enrichment of the records says “none”

What’s wrong

ACF Extended adds a lot to Advanced Custom Fields, and one of its biggest features is front-end forms: a form on the public site that can create or update posts, create or update users, or send email, using ACF fields. Each form has actions, and each action has a target: which post or which user it changes. The target can be fixed (“the current post,” “the current user,” “post 42”) or it can come from a value in the submitted form.

That last option is where all of this lives. When the target comes from the visitor, the plugin has to check that the visitor is allowed to touch it. In 0.9.2.7 and earlier, those checks were missing or inconsistent:

CVE-2026-94267, remote code execution (9.0). The update-post action did no capability check at all. A visitor could point it at any post, including the internal posts where ACF stores field groups and field settings. Rewriting those leads to code execution: ACF Extended’s field validation settings can name PHP functions to run, and 0.9.2.8 now limits them to an allow list. Found by Jakub Herman.
CVE-2026-94268, administrator takeover (8.1). The update-user action has a guard that protects administrator accounts, but the step that checked the target and the step that carried out the update didn’t agree on which user that was. With two form setups on the site, a visitor could slip past the guard, change the administrator’s credentials, and be logged in as them. Found by Jakub Herman.
CVE-2026-94262, account takeover for everyone else (8.1). The same action only checked permission when the target was an administrator. Any other account, such as an editor, a shop manager or a customer, could have its credentials overwritten and a session issued to the visitor. Found by Karthik Ramakrishnan.
CVE-2026-94263, shortcode execution (4.8). Shortcodes in a form’s confirmation message weren’t always switched off for older forms, so a visitor could get shortcodes run on the server. Found by Karthik Ramakrishnan.
CVE-2026-112311, file deletion (6.5 per Patchstack, 9.1 per Wordfence). A path traversal lets an unauthenticated visitor delete files on the server. Deleting wp-config.php drops a site into the install screen, which is why Wordfence rates it so high. Reported by furkan.araspro through Patchstack’s bug bounty.

Are you exposed?

The official records are unusually specific about what each attack needs:

Code execution: a published form whose update-post action takes both its target and its content from visitor-submitted values.
Administrator takeover: two separate published form setups whose targets come from visitor-submitted values.
Other accounts: a published form whose update-user action takes its target from a submitted value instead of the default, the current user.

That’s why the official scores mark these as “high complexity” and not automatable. A site with no ACF Extended forms, or only forms that create posts or edit the logged-in user’s own profile, isn’t exposed to the three serious ones. The file deletion bug is different: its record marks it as automatable, with no special setup listed. Update either way.

Finding your forms

Forms built in the admin live under ACF → Forms. With WP-CLI:

wp post list --post_type=acfe-form --fields=ID,post_title,post_status

Forms can also be registered in code, so search your theme and custom plugins as well:

grep -rn "acfe_register_form\|acfe_form(" wp-content/themes wp-content/plugins --include=*.php | grep -v "plugins/acf-extended"

For each form, open its Actions and look at every Post and User action. If the action updates rather than creates, and its target is set from a field or a submitted value, not “Current post” or “Current user,” that form is the exposed setup. Then check where it’s used. A form only on a page behind a login is a smaller risk than one on a public page, but “behind a login” still includes every customer and subscriber account.

What to do

1. Update

wp plugin list --fields=name,status,version | grep -i acf

Anything below 0.9.2.8 is vulnerable. The free version updates from WordPress.org as usual. PRO updates come through your ACF Extended license, so if the license has lapsed, the dashboard may never have offered the update. Download it from your account instead.

One thing to test after updating: 0.9.2.8 now restricts the arguments the [acfe_form] shortcode accepts to an allow list, and switches off shortcodes in older forms’ success messages. If a form passed other arguments through the shortcode, it may behave differently. The acfe/form/shortcode/allowed_args filter lets you add arguments back deliberately.

2. If you can’t update today

Unpublish any form from the section above, or change its targets to “Current post” and “Current user.” For the file deletion bug there’s no setting to change, so the update is the fix.

3. Check whether you were hit

Nobody has reported attacks, but the details are now public. If you had an exposed form, look:

Users: administrators you didn’t create, and existing accounts whose email address or password changed without the owner doing it. Password changes aren’t logged by default, so ask your users if anything seems off.
Field groups: changes to ACF field groups you didn’t make, especially new validation settings. wp post list --post_type=acf-field-group,acf-field --orderby=modified --order=DESC --fields=ID,post_title,post_modified | head -20 shows the most recently changed.
Posts: content changed by nobody you know. Revisions show what changed and when.
Files: a missing wp-config.php or other deleted files, and any new PHP file in uploads/.
Logs: POST requests to the pages that hold your forms, especially repeated ones from the same address.

If you find signs of a takeover, treat the site as compromised: restore from a clean backup, reset every password, log out all sessions and rotate the salts in wp-config.php. The remote-access audit covers the places an attacker likes to leave a way back in.

Where sources disagree

Severity. The official records (from WPScan) score the code execution bug 9.0 and the account takeovers 8.1, because each needs a specific form setup. Wordfence lists the code execution and administrator takeover at 9.8. Patchstack scores the file deletion 6.5, and Wordfence scores it 9.1.
How many CVEs. Some coverage lists three. The official records have five, from three researchers, all fixed in 0.9.2.8.
Exploitation. No source reports attacks so far. That tends to change once the details are public, so don’t read “none yet” as “none coming.”

The bigger lesson

Every one of these bugs is the same question asked badly: who is this request allowed to change? A front-end form that edits “the post with this ID” or “the user with this ID,” where the ID arrives from the browser, is a form that lets strangers choose their target. The plugin has to get the permission check right every time, at every step, and here it didn’t.

The safer pattern is to never let the visitor pick. Use fixed targets, like “Current post” or “Current user,” and resolve them on the server, not from anything in the request. It’s the same lesson as the Wholesale Lead Capture upload bug, where the plugin let the visitor send the list of allowed file types: anything the browser sends is a suggestion, not a fact. Forms are where WordPress sites accept input from the whole internet, and they deserve the most suspicion of anything you build.

ACF Extended CVE-2026-94267: Five Front-End Form Flaws, One Root Cause