Brief Summary: CVE-2026-6228 Privilege Escalation in Frontend Admin by DynamiApps for WordPress

Introduction

A privilege escalation flaw in the Frontend Admin by DynamiApps WordPress plugin lets an unauthenticated attacker register an account, craft a malicious form, and promote themselves to administrator, with no interaction from the site owner. The plugin has more than 10,000 active installations and over 944,886 total downloads. Because so many sites use it for frontend content management, CVE-2026-6228 is a meaningful risk for the WordPress deployments that depend on it.

Frontend Admin by DynamiApps (WordPress slug: acf-frontend-form-element) lets users manage content, edit posts, and configure permissions from the WordPress frontend without opening the dashboard. It fills a narrow but important niche: sites that need to give non-technical users access to administrative workflows.

Technical Information

Root Cause: Capability Mapping and Missing Authorization

The vulnerability comes from two separate but related design flaws in how the plugin handles forms.

Overly permissive custom post type registration. The plugin registers the admin_form custom post type with 'capability_type' => 'page'. In WordPress, this maps the post type's capabilities to those of the built-in page post type. As a result, any user with the editor role, which has capabilities like edit_pages and publish_pages by default, can automatically create and edit admin_form posts. That is the first link in the exploitation chain, because editors can now create forms that were likely meant for administrators only.

The registration is in post-types.php:

'capability_type' => 'page'

This one line at post-types.php#L53 is what gives editors access to the form builder.

Insufficient authorization in role assignment. The pre_update_value() function in class-role.php checks on lines 107 through 110 that a submitted role value exists in the form's role_options array. That check only confirms the role is "allowed by the form configuration." It never checks whether the current user has the WordPress capability to assign that role. The function treats the form configuration as the only source of truth for which roles are permitted. That is a critical flaw, because editors can change that configuration, as described above.

The vulnerable logic is in class-role.php#L113.

Exploitation Flow

The attack has three stages, each building on the one before.

Stage 1: Unauthenticated registration as editor. The attacker finds a WordPress site running a vulnerable version of Frontend Admin that exposes a public new_user form. By design, this form lets unauthenticated visitors register accounts. The attacker registers and receives editor-level privileges. The unauthenticated attack path depends on a public registration form being available.

Stage 2: Form creation with injected role options. Now logged in as an editor, the attacker uses the 'capability_type' => 'page' mapping to create a new admin_form of type edit_user. Normally the plugin's UI function feadmin_get_user_roles() limits which roles appear in the form builder. The attacker skips the UI entirely and sends a crafted POST request straight to wp-admin/post.php, adding administrator to the form's role_options array. The server-side code does not revalidate the role options against the current user's capabilities when it saves the form, so the malicious configuration is stored.

Stage 3: Privilege escalation via form submission. The attacker submits the crafted edit_user form against their own account and selects administrator as the role. The pre_update_value() function in class-role.php checks whether administrator is in the form's role_options array. The attacker put it there in Stage 2, so the check passes. No other authorization check runs, and the account is promoted to administrator.

The whole chain, from unauthenticated visitor to full administrator, needs no interaction from the site owner and has low attack complexity over the network.

CWE Classification

This vulnerability is classified under CWE-269: Improper Privilege Management. The classification fits: the plugin does not enforce proper authorization boundaries when it assigns roles.

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. Version 3.29.1 contains the fix, and the latest patched release is 3.29.3.

Sites are most at risk if they meet these conditions:

• Running Frontend Admin version 3.28.36 or earlier
• Exposing a public new_user form that allows visitor registration
• Having the default WordPress capability mappings for the editor role intact

Sites without public registration forms are still at risk if any existing editor account is compromised, because any authenticated editor can carry out Stages 2 and 3.

Vendor Security History

The Frontend Admin plugin has had several security issues in a relatively short period, and they keep turning out to be the same kind of flaw:

All three come from insufficient validation and authorization checks in the plugin's form handling and role assignment logic. Each fix closed one specific case. The underlying architectural pattern, trusting form configuration data without checking the user's capabilities, has survived 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)