WordPress runs a large share of the web, and its plugin ecosystem is where most of its security incidents originate. CVE-2026-6228 is a particularly clean example of how a small authorization oversight in a single plugin can hand an attacker the keys to an entire site. Recorded in the National Vulnerability Database and reported by Wordfence, the flaw affects the Frontend Admin by DynamiApps plugin in all versions up to and including 3.28.36, and it allows an unauthenticated attacker to walk themselves up to full administrator privileges.
The escalation chain described in the NVD record is methodical, and understanding it shows exactly where the trust assumptions break. Frontend Admin lets site owners build forms that front-end users can use to manage content and accounts. The plugin’s custom post type for these forms, admin_form, is registered with 'capability_type' => 'page'. That single configuration choice means anyone with the editor role — who can normally create and edit pages — can also create and edit these admin forms. That is the first crack.
How the chain works
According to the description, an editor can create an edit_user form and then “manipulate the form configuration to include ‘administrator’ in the role_options array by directly submitting POST data to wp-admin/post.php, bypassing the UI restrictions in feadmin_get_user_roles().” In other words, the plugin’s interface tries to prevent an editor from offering “administrator” as an assignable role, but that restriction lives only in the front-end UI. By crafting the raw POST request directly, the attacker sidesteps the cosmetic guardrail and writes “administrator” into the form’s list of allowed roles.
The decisive failure comes when the form is used. The NVD record states that the pre_update_value() function in class-role.php “only validates that the submitted role exists in the form’s role_options array… but fails to verify that the current user has permission to assign that specific role.” That is the entire bug in one sentence. The plugin checks whether the requested role is on the form’s menu, but never asks the more important question: is the person submitting this form actually allowed to grant that role? Because the attacker themselves placed “administrator” on the menu in the previous step, the check passes trivially.
Stringing it together, the full attack is: an unauthenticated visitor registers as an editor through a public new_user form the site exposes; that editor creates an edit_user form with “administrator” in the allowed roles via a direct POST; and the editor then submits that form to set their own role to administrator. No stolen credentials, no social engineering — just three crafted requests that exploit a missing permission check.
The CWE class: improper privilege management
NVD classifies the flaw as CWE-269: Improper Privilege Management. CWE-269 covers software that does not properly assign, track, or enforce the privileges a user is entitled to — it lets an actor obtain a level of access beyond what their role should permit. That is exactly what happens here: the code conflates “this role is an option on the form” with “this user may assign this role,” and the conflation lets a lower-privileged account grant itself a higher one. The right design is to validate every role assignment against the assigning user’s capabilities at the moment of the write, never against attacker-controllable configuration.
Why the CVSS is 8.8 High
The record carries a CVSS v3.1 base score of 8.8 (High), vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The attack is over the network (AV:N, plain HTTP requests) with low complexity (AC:L). The vector lists Privileges Required as Low (PR:L) — reflecting that the decisive step is taken as an editor — though the description emphasizes that an attacker can self-register to obtain that editor role unauthenticated, which is what makes the practical barrier so thin. User interaction is None (UI:N), and the impact is High across confidentiality, integrity, and availability (C:H/I:H/A:H) because administrator access on WordPress is total: an admin can install plugins, execute code, exfiltrate data, and deface or destroy the site. That combination — network-reachable, trivially complex, full impact — is what puts it at 8.8.
What is affected and how to remediate
The affected software is the Frontend Admin by DynamiApps WordPress plugin (slug acf-frontend-form-element) in versions up to and including 3.28.36. The patch is delivered in the changeset referenced by the record on the WordPress plugin repository; site administrators should update to the latest patched release immediately. Because the attack can begin with self-registration, sites that allow open user registration and use this plugin are at the highest risk and should treat the update as urgent.
Defenders who cannot patch instantly should, as interim measures, disable open registration, audit existing user accounts for any unexpected administrators, and review the plugin’s forms for unexpected role options. The practical takeaway for the broader WordPress audience is to remember that UI-level restrictions are not security controls — the moment a check that gates privilege lives only in the front end, an attacker who can speak raw HTTP simply ignores it. Real authorization has to be enforced server-side against the acting user’s capabilities, every time a privileged value is written.
It is also worth situating this bug in the wider pattern of WordPress plugin privilege-escalation reports, because the shape recurs constantly: a feature meant to let lower-privileged users perform a narrow task is registered with capabilities that are too broad, and an authorization check is enforced in the wrong place or against the wrong subject. The 'capability_type' => 'page' choice here was almost certainly a convenience — reusing the page capability map so editors could manage forms — but convenience in capability assignment is exactly where these chains start. For site operators, the defensive habit that pays off is least privilege applied to roles themselves: grant the editor role only to people who genuinely need it, scrutinize plugins that expose front-end account or role management, and assume that any plugin combining public registration with role-editing forms is a high-value escalation target until proven otherwise.