Exploitation Research Plan - CVE-2026-6228

1. Vulnerability Summary

The Frontend Admin by DynamiApps plugin (<= 3.28.36) contains a privilege escalation vulnerability. The root cause is a combination of overly permissive access to the admin_form custom post type and insufficient validation in the user role update logic.

Because the admin_form post type uses 'capability_type' => 'page', any user with the Editor role can create and modify these forms. An attacker can register as an Editor (using a public "New User" form), create an "Edit User" form, and manipulate the form's configuration via wp-admin/post.php to include the administrator role in the allowed roles list (role_options). The plugin's validation logic in class-role.php::pre_update_value() only checks if the submitted role is in the form's allowed list but fails to check if the user performing the update has the authority to assign that specific role.

2. Attack Vector Analysis

• Vulnerable Endpoints:
  1. wp-admin/post.php: Used by an Editor to save the admin_form configuration.
  2. admin-ajax.php or the frontend form submission path: Used to submit the "Edit User" form.
• Authentication: Requires Editor privileges. However, the vulnerability description suggests an unauthenticated attacker can reach this by first using a public "New User" form to register as an Editor.
• Payloads:
  1. A POST request to post.php to update an admin_form's metadata, injecting 'administrator' into the role_options array.
  2. A frontend POST request (form submission) to change the current user's role.
• Preconditions:
  • Plugin must be active.
  • An "Edit User" form must be created by the attacker (as an Editor).

3. Code Flow

1. Entry Point 1 (Configuration): Editor visits wp-admin/post.php to save an admin_form.
2. Sink 1: The admin_form settings are saved. The attacker intercepts the save request and adds administrator to the role_options field (likely an ACF-based field).
3. Entry Point 2 (Execution): The attacker navigates to the frontend page where the "Edit User" form is rendered.
4. Processing: The form is submitted. The plugin calls pre_update_value() in main/fields/class-role.php (inferred path).
5. Vulnerable Logic:

   // main/fields/class-role.php (logic described in vulnerability)
   public function pre_update_value($value, $post_id, $field) {
       $role_options = $field['role_options']; // Attacker controlled via configuration
       if (in_array($value, $role_options)) {
           return $value; // Validates against form config, NOT WP capabilities
       }
   }
   

6. Sink 2: The user's role is updated via wp_update_user() or WP_User::set_role().

4. Nonce Acquisition Strategy

The plugin uses nonces for form submission and AJAX actions. Since we need to act as an Editor first, we can extract nonces from the page source.

1. Form Configuration Nonce: When editing the admin_form in the dashboard, the standard WordPress _wpnonce for post.php is required.
2. Frontend Form Nonce: The frontend forms (ACF Frontend) typically localize a nonce.
   • Action: Look for wp_localize_script calls in the source.
   • JS Variable: Likely frontend_admin or acf_frontend.
   • Key: nonce or ajax_nonce.
3. Acquisition Steps:
   • Create a page with the form: wp post create --post_type=page --post_status=publish --post_content='[acf_frontend_form form_id="XXX"]'.
   • Navigate to the page using browser_navigate.
   • Execute: browser_eval("window.acf_frontend?.nonce") or check for hidden input _acf_nonce.

5. Exploitation Strategy

Phase 1: Unauthenticated Editor Registration

• Goal: Register a new user with the "Editor" role.
• Action: Locate a public "New User" form created by the plugin. If none exists, find the shortcode and create one via WP-CLI.
• Payload: Submit the registration form, ensuring the role parameter (if hidden) is set to editor.

Phase 2: Form Configuration Manipulation

• Goal: Create/Edit an "Edit User" form and allow it to assign the "Administrator" role.
• Request: POST /wp-admin/post.php
• Parameters:
  • action: editpost
  • post_ID: The ID of the admin_form.
  • Find the ACF field key for role_options. It will likely look like acf[field_xxxxxx].
  • Inject administrator into the array: acf[field_xxxxxx][]=administrator.

Phase 3: Privilege Escalation

• Goal: Use the manipulated form to escalate the Editor account to Administrator.
• Request: POST to the page containing the form (or admin-ajax.php if it's an AJAX form).
• Parameters:
  • acf[field_role_key]: administrator
  • _acf_form: Base64 encoded form settings.
  • _acf_nonce: Extracted from the frontend page.

6. Test Data Setup

1. Plugin Setup: Ensure acf-frontend-form-element is active.
2. Form Creation:
   • Use WP-CLI to create an admin_form post:
     wp post create --post_type=admin_form --post_title="Escalator" --post_status=publish
3. Target Page:
   • Create a page to host the form:
     wp post create --post_type=page --post_title="Edit Me" --post_status=publish --post_content='[acf_frontend_form post_id="current_user" form_id="THE_FORM_ID"]'

7. Expected Results

• Phase 2: The admin_form metadata should now contain administrator in the role_options list.
• Phase 3: The response should indicate a successful update (HTTP 200 or a redirect).
• The Editor user's role in the database should change from editor to administrator.

8. Verification Steps

1. Check User Role: wp user get <attacker_user_id> --field=roles
2. Confirm Admin Access: Use the attacker's cookies to request /wp-admin/settings-general.php. A successful response (200 OK) confirms administrative access.
3. Inspect Form Meta: wp post primary-meta get <form_id> role_options (to confirm the bypass worked).

9. Alternative Approaches

• Direct Meta Update: If the Editor can update any post meta (due to ACF Frontend permissions), they might be able to update their own wp_capabilities meta directly via a generic "Edit Post" form if not properly restricted.
• REST API: Check if wp-json/acf-frontend/v1/forms endpoints exist and allow form configuration updates without proper capability checks on the role_options field.
• Pre-existing Admin Form: If the site already has an "Edit User" form for staff, an Editor might just be able to use it if role_options wasn't strictly defined, or if they can modify the existing form's options.