Introduction
A privilege escalation flaw in the Frontend Admin by DynamiApps WordPress plugin allows an unauthenticated attacker to register an account, craft a malicious form, and promote themselves to administrator, all without any user interaction from the site owner. With over 10,000 active installations and nearly one million total downloads, this plugin's role in enabling frontend content management makes CVE-2026-6228 a meaningful risk for WordPress deployments that rely on it.
Frontend Admin by DynamiApps (WordPress slug: acf-frontend-form-element) is a plugin that allows users to manage content, edit posts, and configure permissions directly from the WordPress frontend without accessing the dashboard. The plugin has accumulated over 944,886 total downloads and serves more than 10,000 active sites. It occupies a niche but important role in the WordPress ecosystem for sites that need to expose administrative workflows to non technical users.
Technical Information
Root Cause: Capability Mapping and Missing Authorization
The vulnerability originates from two distinct but interrelated design flaws in the plugin's form handling architecture.
Overly permissive custom post type registration. The plugin registers the admin_form custom post type with 'capability_type' => 'page'. In WordPress, this configuration maps the post type's capabilities to those of the built in page post type. The practical consequence is that any user with the editor role, which by default has capabilities like edit_pages and publish_pages, automatically gains the ability to create and edit admin_form posts. This is the first link in the exploitation chain: editors can create forms that were likely intended to be restricted to administrators.
The relevant registration can be found in post-types.php:
'capability_type' => 'page'
This single line at post-types.php#L53 is what grants editors access to the form builder.
Insufficient authorization in role assignment. The pre_update_value() function in class-role.php performs a validation check on lines 107 through 110 to confirm that a submitted role value exists within the form's role_options array. However, this check only validates that the role is "allowed by the form configuration" and never verifies whether the currently authenticated user has the WordPress capability to assign that role. The function trusts the form configuration as the sole source of truth for what roles are permissible, which is a critical flaw because, as established above, editors can manipulate that configuration.
The vulnerable logic resides in class-role.php#L113.
Exploitation Flow
The attack proceeds through three stages, each building on the previous one:
Stage 1: Unauthenticated registration as editor. The attacker identifies a WordPress site running a vulnerable version of Frontend Admin that exposes a public new_user form. This form, by design, allows unauthenticated visitors to register accounts. The attacker registers an account and obtains editor level privileges. The availability of a public registration form is a prerequisite for the unauthenticated attack path.
Stage 2: Form creation with injected role options. Now authenticated as an editor, the attacker leverages the 'capability_type' => 'page' mapping to create a new admin_form of type edit_user. The plugin's UI function feadmin_get_user_roles() normally restricts which roles appear in the form builder interface. However, the attacker bypasses this UI restriction entirely by crafting a direct POST request to wp-admin/post.php. In this request, the attacker manipulates the form configuration to include administrator in the role_options array. Because the server side code does not re validate the role options against the current user's capabilities when saving the form, the malicious configuration is persisted.
Stage 3: Privilege escalation via form submission. The attacker submits the crafted edit_user form, targeting their own account and selecting administrator as the desired role. The pre_update_value() function in class-role.php checks whether administrator exists in the form's role_options array. Since the attacker injected it in Stage 2, the check passes. No further authorization verification occurs, and the attacker's account is promoted to administrator.
The entire chain, from unauthenticated visitor to full administrator, requires no user interaction from the site owner and operates with low attack complexity over the network.
CWE Classification
This vulnerability is classified under CWE-269: Improper Privilege Management, which accurately captures the failure to enforce proper authorization boundaries during role assignment operations.
Affected Systems and Versions
The vulnerability affects the Frontend Admin by DynamiApps plugin for WordPress in all versions up to and including 3.28.36. The fix was introduced in version 3.29.1, and the latest available patched release is 3.29.3.
Sites are particularly vulnerable if they meet the following conditions:
- Running Frontend Admin version 3.28.36 or earlier
- Exposing a public
new_userform that allows visitor registration - Having the default WordPress capability mappings for the editor role intact
Sites that do not expose public registration forms are still at risk if any existing editor account is compromised, as Stages 2 and 3 of the attack can be executed by any authenticated editor.
Vendor Security History
DynamiApps has faced multiple security issues in the Frontend Admin plugin over a relatively short period. The pattern is notable for its consistency in the type of flaw:
| CVE Identifier | Vulnerability Type | Affected Versions | Impact |
|---|---|---|---|
| CVE-2025-13342 | Unauthorized modification | Up to 3.28.20 | Allowed unauthenticated attackers to modify critical WordPress options like users_can_register and default_role |
| CVE-2025-14736 | Privilege Escalation | Up to 3.28.29 | Allowed unauthenticated attackers to register as administrators via insufficient validation of role values |
| CVE-2026-6228 | Privilege Escalation | Up to 3.28.36 | Allows unauthenticated attackers to escalate to administrator via crafted edit_user forms |
All three vulnerabilities share a common theme: insufficient validation and authorization checks in the plugin's form handling and role assignment logic. Each successive fix addressed a specific manifestation of the problem, but the underlying architectural pattern of trusting form configuration data without verifying user capabilities has persisted across multiple releases.
References
- Wordfence Vulnerability Advisory for CVE-2026-6228
- CVE Record: CVE-2026-6228
- post-types.php source (WordPress Plugin Repository)
- class-role.php source (WordPress Plugin Repository)
- user.php source (WordPress Plugin Repository)
- Changeset 3519460 (WordPress Plugin Repository)
- Frontend Admin by DynamiApps on WordPress.org
- Wordfence Plugin Security Overview for Frontend Admin
- CVE-2025-13342 (NVD)
- CVE-2025-14736 (NVD)



