CVE-2026-75816 carries a 9.8 and lets an unauthenticated visitor take over any WordPress account on a site running Frontend Admin by DynamiApps 3.29.12 or earlier. The version that fixed it shipped 12 days ago, described in the changelog as improved permission checks.
What happened
Wordfence published CVE-2026-75816 to the National Vulnerability Database at 3:17 a.m. UTC on Sunday, September 6, 2026. It is scored CVSS v3.1 9.8 on the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, classified CWE-287, Improper Authentication, and it affects the WordPress plugin Frontend Admin by DynamiApps in “all versions up to, and including, 3.29.12.” The plugin reports more than 9,000 active installations on WordPress.org.
The CVE description is unusually specific about the mechanism, and it is worth reproducing in full because the wording is the story. The plugin is vulnerable, it says, “due to the pre_update_value function lacking any capability or ownership check, and ActionPost::conditions_logic() short-circuiting its current_user_can(‘edit_post’) authorization gate whenever the post ID is non-numeric — such as the string user_1 — allowing unauthenticated form submissions to be routed to arbitrary user records without restriction.”
Read that gate carefully. current_user_can('edit_post') is a per-object capability check: you hand it a post ID and WordPress tells you whether the current user may edit that specific post. Frontend Admin’s action pipeline routes submissions to more than posts — the plugin’s own field set covers users, terms, and WooCommerce products — and a user record is addressed with an identifier like user_1, which is not an integer. When the identifier does not look like a post, the gate does not deny. It short-circuits, and the submission proceeds to pre_update_value, which the CVE says carries no capability or ownership check of its own. Two checks, neither of which runs on the path that matters.
The fixed release is 3.29.13. According to the plugin’s changelog on WordPress.org, it shipped on August 25, 2026, and its entry reads, in full: “Improved handling of the custom upload directory setting; Improved permission checks in the Post, Term, and Product actions; Improved validation when dynamically loading a form.”
The releases immediately before it matter too. Versions 3.29.11 and 3.29.12 both carry the date 19-08-2026 in the changelog — August 19, 2026 — and both are security releases. Version 3.29.11 lists eight items, most of them authorization work: it “Restricted the inline field update endpoint and the User Password field so updates can only be made to objects the requesting user is authorized to edit,” “Fixed a permission check bypass when editing or creating users through a crafted request,” “Restricted which roles can be assigned through a Role field so privileged roles can no longer be self-assigned without permission,” “Added a missing permission check to the Plan deletion endpoint,” and “Fixed a permission check bypass in the Delete Button field that could allow deleting posts, products, or users without proper authorization,” alongside a stored XSS fix in the Steps and Step blocks. Version 3.29.12, released the same day, hardened the Role field further and “Fixed the New User role safeguard to check the correct permission instead of matching a specific role name.”
So the sequence is three security releases in seven days, and CVE-2026-75816 says the account takeover survived the first two. A site that installed 3.29.11 on August 19, read a changelog full of permission-check fixes, and concluded it was current was still fully exposed.
Why it matters
The bug is an authorization check that tests the wrong thing, and the way it fails is the part worth carrying forward. A capability gate keyed to an object identifier has an implicit contract: the identifier names an object of the type the gate understands. Frontend Admin routes several object types through one pipeline but gates it with a post-shaped check, and the code treats “this is not a post” as a case with nothing to authorize rather than a case to refuse. That is a fail-open default sitting directly on the unauthenticated path.
The tell is that the attacker does not need to forge anything, guess a nonce, or win a race. The string user_1 is not an exploit payload; it is the plugin’s own internal addressing scheme for the first user account, which on a stock WordPress install is the original administrator. The submission that takes over the site looks like a submission the plugin was built to accept. There is no anomaly in the request shape for a WAF to key on, which is why version identification, not traffic filtering, is the control that actually works here.
The second issue is the changelog line, and it is the more common failure. “Improved permission checks in the Post, Term, and Product actions” is accurate — that is what the fix does — and it is also indistinguishable from routine hardening. Every plugin ships lines like it. Nothing in that sentence tells an administrator that the release closes an unauthenticated path to administrator account takeover, and nothing distinguishes it from the far longer, far more alarming-sounding list in 3.29.11, which does not close it. An operator triaging an update queue by changelog urgency would rank 3.29.13 below 3.29.11 and below 3.29.12. That ordering is exactly backwards.
For 12 days, from August 25 to September 6, that changelog line was the only public signal this bug existed. This publication has repeatedly found the same shape — a vendor changelog that understates a critical fix, with the CVE arriving days or weeks later to supply the missing severity — and the practical consequence is always the same. The window between the fix and the CVE is a window in which the people who most need to patch have no way to know they should, while the diff is public and anyone reading it can see what changed.
There is a narrower lesson for anyone maintaining code with this structure. A burst of authorization releases is a signal that the authorization model, not any single check, is what needs review. Frontend Admin shipped five separate permission-bypass fixes on August 19 and a sixth on August 25. When that many gates in one plugin turn out to be missing or misapplied within a week, the useful question is not whether each patch is correct but whether the pipeline should be enforcing authorization centrally, at the point where a submission is bound to a target object, instead of at each field and action that happens to remember to ask.
What to do
Update Frontend Admin by DynamiApps to 3.29.13 or later. Anything at or below 3.29.12 is in the stated affected range, including 3.29.11 and 3.29.12 themselves, which read as security releases and are not sufficient here. From WP-CLI: wp plugin get acf-frontend-form-element --field=version, and wp plugin update acf-frontend-form-element. The plugin’s directory slug is acf-frontend-form-element, which does not match its display name — worth knowing if you are grepping an inventory.
If the site ran 3.29.12 or earlier with any Frontend Admin form reachable without logging in, treat administrator accounts as potentially compromised until you have checked. Look for administrator email address changes you cannot account for, password changes with no matching reset request, and new accounts created around unexplained form submissions. In web server logs, look for POST requests to the plugin’s form-handling endpoints carrying a post ID parameter whose value is not an integer — the CVE names user_1 as the example, and any non-numeric value in that position is the signature of the bypass rather than of normal use.
Rotate administrator passwords and application passwords on affected sites, and check for unexpected changes to user roles as well as passwords; the same pipeline handles role assignment, and 3.29.11 and 3.29.12 were both fixing role-assignment bypasses. Enabling two-factor authentication is worth doing but is not the control that closes this one — the flaw writes to the user record directly, so a second factor gates the login that follows rather than the takeover itself.
Sourcing note
Checked: the NVD record for CVE-2026-75816, which supplied the description, CVSS vector, CWE, affected range, and reference list, and which was published and last modified at 3:17 a.m. UTC on September 6, 2026; the plugin listing and changelog on WordPress.org, which supplied the fixed version, the release dates for 3.29.10 through 3.29.13, the changelog text quoted above, and the active-installation figure. Wordfence is the CNA of record.
Not reached: the WordPress plugin trac changeset the CVE cites as reference 6 — changeset/3664865/acf-frontend-form-element — returned HTTP 429 on repeated attempts, so the fix diff was not read directly. The five source-line references in the CVE point at tag 3.29.10 rather than at 3.29.12, the last affected version; that is the CNA’s citation choice, and this story does not read anything into it. The rendered Wordfence threat-intelligence entry for this CVE loads its content with JavaScript and returned no text to automated fetching, so the researcher credit and Wordfence’s own publication date were not confirmed.
Unresolved: whether the vulnerable path requires a specific Frontend Admin form to be published and publicly reachable. The CVE describes the submissions as unauthenticated and states no precondition beyond that, and this story does not add one. No exploitation of CVE-2026-75816 has been reported by the vendor, by Wordfence, or by any source reviewed for this piece.