Frontend Admin by DynamiApps CVE-2026-75816: Update to 3.29.13 — Unauthenticated Admin Takeover

The WordPress plugin Frontend Admin by DynamiApps (slug `acf-frontend-form-element`) has a CVSS 9.8 (CRITICAL) authentication bypass, CVE-2026-75816. It affects all versions up to and including 3.29.12 and is fixed in 3.29.13.

The worst case is a full administrator account takeover. An attacker who is not logged in overwrites the administrator's registered email address with their own, then runs WordPress's native password reset. No user interaction is required.

Version 3.29.13 was published on 25 August 2026, while the CVE became public on 6 September. In other words, the fix has been available for two weeks. Sites still running 3.29.12 or earlier are the ones at risk. WordPress.org reports roughly 9,000 active installs for this plugin.

Do this now

• ✓Update the plugin to 3.29.13 or later. As of 8 September 2026, the latest version distributed by WordPress.org is 3.29.13 (released 25 August 2026)
• ✓Check the installed version first. Use the Plugins screen, or WP-CLI: `wp plugin get acf-frontend-form-element --field=version`
• ✓If you run several sites, sweep them. Run `wp plugin list --format=csv` on each and collect the version of `acf-frontend-form-element`
• ✓After updating, look for signs of a takeover. Open the Users screen and review every administrator account and its email address for changes you did not make, and for administrators you do not recognise
• ✓Search the administrator's mailbox for notification mail. As explained under "How to tell whether you were taken over", WordPress core sends a notice to the previous address when an email address changes
• ✓If you genuinely cannot update yet, deactivate the plugin for now. Your front-end submission forms stop working, which is the lighter of the two risks compared with an unauthenticated admin takeover

Where this score comes from. The 9.8 above is the CVSS v3.1 score assigned by Wordfence, the CNA for this CVE. The vector is `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H` and the weakness is classified as CWE-287 (Improper Authentication).

NVD does not yet carry a Primary score from NIST itself. As of 8 September 2026 the record status is `Received`, and the value above appears on NVD as Secondary. NIST may publish a different number later.

CISA's own SSVC assessment, recorded on 7 September 2026, is also worth reading: exploitation: none (no exploitation observed), automatable: yes (it can be attacked at scale automatically), technicalImpact: total. In short, no attacks have been observed yet, but a public agency has judged this to be the kind of flaw that automates well. It is not listed in the KEV catalog as of 8 September 2026.

The defect: a non-numeric post_id skipped the capability check

This plugin lets site owners place front-end forms that edit posts and user records. The edit target is identified by a value called `post_id`.

The post editing path (`ActionPost::conditions_logic()`) does contain a capability check, `current_user_can( 'edit_post', $post_id )`. The problem was an early return that sat in front of it. Here is the 3.29.12 code:

// 3.29.12 — main/frontend/forms/actions/post.php
$post_id = $settings['post_id'] ?? 'none';

if( ! is_numeric( $post_id ) ){
    return $settings;   // <- not numeric? return before reaching the capability check
}

if ( ! current_user_can( 'edit_post', $post_id ) ) {
    // this is where the request should have been rejected
}

If `post_id` is not numeric, the settings are returned without any capability check at all. According to the CVE description, passing a non-numeric string such as `user_1` is what routes an unauthenticated form submission to an arbitrary user record.

The fix in 3.29.13 inverts the meaning of that early return:

// main/frontend/forms/actions/post.php

+ // 'none' and 'add_post' are the only legitimate non-numeric states;
+ // anything else is unexpected input and must not bypass the capability check below.
+ if ( in_array( $post_id, array( 'none', 'add_post' ), true ) ) {
+     return $settings;
+ }
+
  if( ! is_numeric( $post_id ) ){
-     return $settings;
+     $settings['post_id'] = 'none';
+     return $settings;
  }

Only the legitimate non-numeric values (`none` and `add_post`) are allowed through explicitly; every other non-numeric value is collapsed to `none`. We verified this diff by reading the 3.29.12 and 3.29.13 tags directly in the official WordPress.org plugin repository (SVN).

Note also that this plugin shipped three consecutive permission fixes in August 2026: 3.29.11 and 3.29.12 on 19 August, and 3.29.13 on 25 August. 3.29.11 restricted a permission bypass when creating or editing users; 3.29.12 added missing permission checks to the Email, Display Name and Website user fields. Do not stop half way — go to 3.29.13 or later.

What we are not asserting: the full 3.29.12 attack path is not reproducible from public information

When we could not verify something, we say so.

The CVE description names a second half of the chain: the email field's `pre_update_value` lacking any capability or ownership check. Reading the official repository, however, 3.29.11 indeed has no such check, while the same function in 3.29.12 already contains `current_user_can( 'edit_user', $user_id )`.

So what we confirmed with our own eyes is this:

(1) In 3.29.11 and earlier, the email field itself was unprotected.
(2) In 3.29.13, the capability-check bypass in the post action was closed.

The affected range "all versions up to and including 3.29.12" is taken as published by Wordfence, the CNA. We could not reconstruct, from public information alone, the exact path that remained open in 3.29.12. Either reading leads to the same action: move to 3.29.13 or later.

How to tell whether you were taken over

The final step of this attack is "change the email address, then reset the password" — and WordPress core leaves a trace there.

When `wp_update_user()` changes a user's email address, core sends a notice with the subject `[Site Name] Email Changed` to the previous address, confirming that the address was changed to the new one. This plugin writes the new address through that same `wp_update_user()` call, so if the attack succeeded, an unexpected notice should be sitting in the administrator's original mailbox.

• ▸Search the administrator's mailbox for "Email Changed". The subject stays in English even on non-English sites
• ▸Review the email address of every administrator account on the Users screen. Look for unfamiliar domains
• ▸Look for user accounts you did not create, especially administrators.
• ▸No notice does not mean you are safe. The `send_email_change_email` filter can suppress it, and the mail may simply have failed to deliver. Do not conclude you were untouched because nothing arrived
• ▸If you find traces, rotate every administrator password and check posts, plugin and theme files for tampering. Restoring the email address is not the end of the job

The takeaway

"If the input is unexpected, just let it through" is a classic way to skip an authorization check. The early return here was almost certainly written to mean "a non-numeric ID is not an edit target, so this rule does not apply". But because the capability check lived behind that rule, anyone who sent an unexpected value slipped past the check along with the rule.

Default to deny, not allow, when you meet input you did not plan for. Collapsing the value to `none`, as the patched code does, is exactly that shape.

One more thing. Front-end editing plugins carry their own permission logic, separate from WordPress core. A correct core capability model does not help if the plugin's own entry point can be bypassed. The more your site opens submission or membership forms to the public, the higher this class of update belongs in your queue.