CVE-2026-94267: ACF Extended Front-End Forms Are Unauth RCE - Floor 0.9.2.8

CVE-2026-94267 is WPScan’s name for unauthenticated remote code execution in Advanced Custom Fields: Extended (acf-extended) and ACF Extended PRO before 0.9.2.8. NVD (CISA Coordinator, Secondary) scores it 9.0 critical (CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H). CWE-94: Improper Control of Generation of Code. CVE state PUBLISHED, NVD vulnStatus Deferred. datePublished 2026-10-23T06:00:21.241Z. WPScan publicly published 2026-10-21. Finder: Jakub Herman. WPScan marks the row Verified / Fixed in 0.9.2.8.[1][2][3]
Same-day siblings, same floor:
- CVE-2026-94268 - unauthenticated administrator account takeover via the front-end update-user action. NVD Secondary 8.1 high (
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). CWE-269. CNA affected range is 0.9.2.7 < 0.9.2.8 only. Finder: Jakub Herman.[4][10][12] - CVE-2026-94262 - unauthenticated non-administrator account takeover on the same update-user path (the admin-role guard is skipped for everyone else). NVD Secondary 8.1 high, same vector. CWE-863. Same 0.9.2.7 < 0.9.2.8 range. Finder: Karthik Ramakrishnan.[5][11][13]
The wordpress.org plugin API this morning returned version 0.9.2.8, active_installs 100000 (the directory’s 100k bucket), last updated 2026-10-19 1:23pm GMT, tested to 7.1.3, requires WP 4.9 / PHP 5.6. Author profile: hwk-fr (Konrad Chmielewski). Homepage: https://www.acf-extended.com. Readme: requires at least ACF Pro 5.8.[6][8]
What it is
This is a plugin Forms module bug, not WordPress core and not PHP2Shell.[1][3]
WPScan / CNA text for 94267: the plugin does not perform any capability check when updating a post through one of its front-end form actions. An unauthenticated visitor can overwrite arbitrary posts, including the posts the site uses to store its own field definitions, which they say leads to arbitrary code execution. Exploitation requires the site to publish a form whose post-update action maps both its target and its content to visitor-submitted values.[1][3]
That last sentence is load-bearing. This is not “any ACF Extended install on the internet.” It is “a public acfe_form (or equivalent) whose post-update action lets the visitor pick which post and what content.”[1][3]
94262 is a different action on the same Forms module: update-user. The authorisation check runs only when the target account is an administrator, so a visitor-mapped target can overwrite any non-admin credentials and get a session.[5][11]
94268 is the same action with a second failure: the plugin does not resolve the target consistently between the authorisation stage and the carry-out stage, so the admin guard can be skipped if the site publishes two front-end forms whose targets are mapped to visitor-submitted values.[4][10]
We did not submit a form, overwrite a post, or mint a session. Treat the “overwrite field-definition posts → RCE” chain and the two-form admin-takeover path as WPScan’s published claim, not as a request we sent.[1][3][4]
Vendor changelog does print matching security bullets, without the CVE IDs:
- 0.9.2.7: “Added security check when updating an admin user (Thanks to Khaled Alenazi)”; “Enhanced user role detection & safeguard logic when updating a user”; shortcode-attribute security fix.[6]
- 0.9.2.8 (19 Oct on wordpress.org): “Enforced capability check for internal post types/taxonomies (Jakub Herman)”; “User Action - Added capability check when updating non-admin users (Karthik Ramakrishnan)”;
[acfe_form]shortcode args restricted to an allow list; Template Tags blocked in shortcode arguments (Karthik Ramakrishnan); validation functions go through an allowed list (Jakub Herman).[6][8]
0.9.2.7 tried to lock the admin user-update path. The CNA for 94268/94262 still lists only 0.9.2.7 as affected. Floor is 0.9.2.8 because that is the current wordpress.org release and it credits both 94267/94268/94262 finders for the capability checks - not because 0.9.2.7 was a complete fix.[4][5][6]
How serious
A 9.0 with C:H I:H A:H, PR:N, and S:C is “unauthenticated, total impact, scope changed.” The AC:H is the form-mapping precondition WPScan wrote into the description. CISA Coordinator SSVC on the NVD object: exploitation: none, automatable: no, technicalImpact: total (timestamp 2026-10-23T10:35:48Z). That is CISA’s published decision track, not a scan we ran.[2][3]
94268/94262 are S:U 8.1s: site takeover / account takeover on the WordPress user table, not a claimed changed-scope RCE.[12][13]
None of the three IDs are in CISA KEV as of catalog 2026.10.23 (dateReleased 2026-10-23T19:30:18.9209Z, 1756 entries). Newest dateAdded on that dump: 23 Oct Collabora CODE / Arista VeloCloud - not WordPress. Absence from KEV is not a clean bill of health.[7]
NVD vulnStatus is Deferred on all three. The 9.0 / 8.1 figures are Secondary from CISA Coordinator (134c704f-…), not an NVD-assigned Primary metric.[2][12][13]
WPScan’s own calculator link on the 94267 page is the same 9.0 vector.[3]
Who is affected
In scope, per the CNA affected blocks:[1][4][5]
- 94267:
acf-extendedandacf-extended-pro< 0.9.2.8 (from version 0). The plant path they published is a front-end post-update form that maps target and content to visitor input. - 94262 / 94268: the same two products, but only 0.9.2.7. Frozen copies on 0.9.2.6 and earlier are out of those two IDs and still in 94267.
- Agencies that put ACF Extended forms on login-less landing pages, membership join flows, or “edit my listing” templates. The CNA trigger is the published form mapping, not “only wp-admin.”
Out of scope unless you have a separate advisory:
- Sites already on 0.9.2.8 (API
versionthis morning is 0.9.2.8).[8] - Advanced Custom Fields / ACF PRO (
advanced-custom-fields). Different slug. ACF Extended requires ACF Pro ≥ 5.8; patching ACF does not bumpacf-extended.[6][8] - WordPress core.
- Sites with ACF Extended installed and no public form whose post-update / user-update action maps target to visitor input. That is a narrower blast radius, not a version exception. The CNA version range does not shrink because you “don’t think you use forms.”[1][3]
wordpress.org advanced stats this morning: 0.9 87.8%, 0.8 12.2%, 0.7 ~0%. The 0.9 bucket includes both 0.9.2.7 (affected) and 0.9.2.8 (current); we cannot split it from that table.[9]
What to do now
- Inventory the slug, not an ACF screenshot.
# one site
wp plugin get acf-extended --field=version --path=/home/USER/public_html
wp plugin list --name=acf-extended --fields=name,status,version --path=/home/USER/public_html
# cPanel box, every account (read-only)
find /home -path '*/wp-content/plugins/acf-extended/acf-extended.php' 2>/dev/null \
| while read -r f; do
ver=$(awk -F': ' '/^[[:space:]]*\*?[[:space:]]*Version:/{print $2; exit}' "$f")
echo "$ver $f"
done
PRO lives outside wordpress.org. If you ship it from the vendor, check that copy the same way (acf-extended-pro). CNA lists both products under < 0.9.2.8.[1]
- Ship 0.9.2.8. That is what wordpress.org is serving. Do not leave a public form on 0.9.2.7 “because 0.9.2.7 already mentioned an admin-user check.”[6][8]
wp plugin update acf-extended --path=/home/USER/public_html
wp plugin get acf-extended --field=version --path=/home/USER/public_html # want 0.9.2.8
- If you cannot update today: unpublish the form, or deactivate. A WAF rule is not a version bump. Closing comments does nothing here; the plant is the Forms module, not
wp-comments-post.php.[1][3]
wp plugin deactivate acf-extended --path=/home/USER/public_html
If the site actually needs the form: take the page that embeds [acfe_form] private / behind auth until 0.9.2.8 is live. We are not publishing a payload.
-
After the bump, look at who owns the site. 0.9.2.8 does not unwind a post that was already overwritten or a user whose password was already changed. If you have reason to hunt: unexpected administrators in
wp_users, password/email changes on editors around 19-23 Oct, field-group posts whose content you did not edit, then rotate WordPress salts and invalidate sessions. Presence of a new admin is a hunt target for any WP incident, not a fingerprint unique to these CVEs. -
Unsupported / frozen lines. 94267
defaultStatusis unaffected except < 0.9.2.8. There is no 0.8.x patched build in the record we pulled. Jump a frozen 0.8 site through staging, or remove the plugin.[1][2][9]
Compromise signs
The published classes are unauth post overwrite → claimed RCE (94267) and unauth user overwrite → session (94262/94268). Hunt for, do not treat as proof:[1][4][5]
- New WordPress administrators you did not create, especially after a public form was live on ≤ 0.9.2.7.
- Editors / shop managers whose email or password changed without a ticket.
- ACF field-group / form posts with
post_modifiedyou cannot explain. - PHP files under
wp-contentdated around the same window that were not part of a deploy.
Absence is not proof of cleanliness. We did not publish a Nuclei template and we did not send a probe.
FAQ
Is this PHP2Shell? No. PHP2Shell is CVE-2026-109618 / 109619 in PHP itself. These IDs are ACF Extended’s Forms module.[1][3]
Do I have to be logged in? CNA / NVD vector is PR:N. WPScan’s RCE row is typed RCE. The AC:H is the published-form mapping, not a login.[2][3]
Does every ACF Extended site get RCE by default? Not according to the CNA. 94267 needs a front-end post-update form that maps both target and content to visitor-submitted values. 94268 needs two such user-update forms. Inventory the plugin version anyway; do not argue yourself out of 0.9.2.8.[1][3][4]
Is 0.9.2.7 enough? No. 0.9.2.7 added an admin-user update check (Khaled Alenazi). 94268/94262 still name 0.9.2.7 as the affected line. 94267 names everything < 0.9.2.8. Floor 0.9.2.8.[4][5][6]
Does this give root on the box? The scored scope for 94267 is changed (S:C) because WPScan frames code execution on the server. That is still the web-server user running PHP, not a claimed KVM or panel root. A written PHP file plus a new admin is still a site-takeover.[2][3]
Is ACF PRO itself vulnerable under these IDs? Not in the CNA affected product list. Patch acf-extended / acf-extended-pro.[1][8]
Honesty / What we could not verify
- We did not exploit this. No form was submitted. No post was overwritten. No session cookie was issued.
- We did not prove the field-definition → RCE step. WPScan states it; we did not reconstruct which internal post type stores field definitions or which write becomes
eval. Treat RCE as their claim, with the capability-check changelog as the part we can read.[3][6] - 100,000 is wordpress.org
active_installsthis morning, not a census we ran. The 87.8% on the 0.9 branch mixes patched and unpatched.[8][9] - Not on CISA KEV as of catalog 2026.10.23 / count 1756. SSVC on the 94267 NVD row is exploitation: none / automatable: no.[2][7]
- NVD status Deferred; 9.0 / 8.1 are CISA Coordinator Secondary, not NVD-assigned Primary.[2][12][13]
- In-the-wild: no source we pulled claimed active exploitation. We did not scan the fleet for these forms.
Sources
[1] https://cveawg.mitre.org/api/cve/CVE-2026-94267 - CVE-2026-94267 CNA [2] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-94267 - NVD CVE-2026-94267 [3] https://wpscan.com/vulnerability/9c8f45c1-cd85-4a9c-be77-88801d8143ce - WPScan 94267 [4] https://cveawg.mitre.org/api/cve/CVE-2026-94268 - CVE-2026-94268 CNA [5] https://cveawg.mitre.org/api/cve/CVE-2026-94262 - CVE-2026-94262 CNA [6] https://plugins.svn.wordpress.org/acf-extended/tags/0.9.2.8/readme.txt - acf-extended 0.9.2.8 readme [7] https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json - CISA KEV JSON [8] https://api.wordpress.org/plugins/info/1.2/?action=plugin_information&request%5Bslug%5D=acf-extended - wordpress.org plugin API acf-extended [9] https://wordpress.org/plugins/acf-extended/advanced - wordpress.org acf-extended advanced stats [10] https://wpscan.com/vulnerability/eccfab3c-e7cc-4623-9c20-4cd6c32f8422 - WPScan 94268 [11] https://wpscan.com/vulnerability/3634e73f-df12-4d84-8bf6-c098efa0b191 - WPScan 94262 [12] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-94268 - NVD CVE-2026-94268 [13] https://services.nvd.nist.gov/rest/json/cves/2.0?cveId=CVE-2026-94262 - NVD CVE-2026-94262