[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fp-gAmO8GmAw_jqKYZqgqY2UxJ9fHh9FED3FRwEzJZJA":3},{"id":4,"url_slug":5,"title":6,"description":7,"plugin_slug":8,"theme_slug":9,"affected_versions":10,"patched_in_version":11,"severity":12,"cvss_score":13,"cvss_vector":14,"vuln_type":15,"published_date":16,"updated_date":17,"references":18,"days_to_patch":20,"patch_diff_files":21,"patch_trac_url":9,"research_status":30,"research_verified":31,"research_rounds_completed":32,"research_plan":33,"research_summary":9,"research_vulnerable_code":9,"research_fix_diff":9,"research_exploit_outline":9,"research_model_used":34,"research_started_at":35,"research_completed_at":36,"research_error":9,"poc_status":9,"poc_video_id":9,"poc_summary":9,"poc_steps":9,"poc_tested_at":9,"poc_wp_version":9,"poc_php_version":9,"poc_playwright_script":9,"poc_exploit_code":9,"poc_has_trace":31,"poc_model_used":9,"poc_verification_depth":9,"poc_exploit_code_gated":31,"source_links":37},"CVE-2026-6228","frontend-admin-by-dynamiapps-unauthenticated-privilege-escalation-via-edit-user-form","Frontend Admin by DynamiApps \u003C= 3.28.36 - Unauthenticated Privilege Escalation via Edit User Form","The Frontend Admin by DynamiApps plugin for WordPress is vulnerable to Privilege Escalation in versions up to and including 3.28.36. This is due to insufficient authorization checks in the role field update mechanism combined with overly permissive capabilities for the admin_form post type. The admin_form custom post type uses 'capability_type' => 'page', which grants editors the ability to create and edit forms. When an editor creates an edit_user form, they can manipulate the form configuration to include 'administrator' in the role_options array by directly submitting POST data to wp-admin\u002Fpost.php, bypassing the UI restrictions in feadmin_get_user_roles(). When the form is subsequently submitted, the pre_update_value() function in class-role.php only validates that the submitted role exists in the form's role_options array (lines 107-110), but fails to verify that the current user has permission to assign that specific role. This makes it possible for unauthenticated attackers to first register as editors (via a public new_user form), then create an edit_user form with administrator in the allowed roles, and finally use that form to escalate their own privileges to administrator.","acf-frontend-form-element",null,"\u003C=3.28.36","3.29.1","high",8.8,"CVSS:3.1\u002FAV:N\u002FAC:L\u002FPR:L\u002FUI:N\u002FS:U\u002FC:H\u002FI:H\u002FA:H","Improper Privilege Management","2026-05-14 19:18:22","2026-05-15 07:46:36",[19],"https:\u002F\u002Fwww.wordfence.com\u002Fthreat-intel\u002Fvulnerabilities\u002Fid\u002F083accd0-8338-47c6-b396-96679b95dd40?source=api-prod",1,[22,23,24,25,26,27,28,29],"acf-frontend.php","assets\u002Fbuild\u002Fblocks\u002Fform\u002Fblock.json","assets\u002Fbuild\u002Fblocks\u002Fpayment-form\u002Fblock.json","assets\u002Fbuild\u002Fblocks\u002Fsteps\u002Fblock.json","assets\u002Fbuild\u002Fform\u002Findex.asset.php","assets\u002Fbuild\u002Fform\u002Findex.js","assets\u002Fbuild\u002Fpayment-form\u002Findex.asset.php","assets\u002Fbuild\u002Fpayment-form\u002Findex.js","researched",false,3,"# Exploitation Research Plan - CVE-2026-6228\n\n## 1. Vulnerability Summary\nThe **Frontend Admin by DynamiApps** plugin (\u003C= 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.\n\nBecause 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\u002Fpost.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.\n\n## 2. Attack Vector Analysis\n*   **Vulnerable Endpoints:** \n    1.  `wp-admin\u002Fpost.php`: Used by an Editor to save the `admin_form` configuration.\n    2.  `admin-ajax.php` or the frontend form submission path: Used to submit the \"Edit User\" form.\n*   **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.\n*   **Payloads:**\n    1.  A POST request to `post.php` to update an `admin_form`'s metadata, injecting `'administrator'` into the `role_options` array.\n    2.  A frontend POST request (form submission) to change the current user's role.\n*   **Preconditions:** \n    *   Plugin must be active.\n    *   An \"Edit User\" form must be created by the attacker (as an Editor).\n\n## 3. Code Flow\n1.  **Entry Point 1 (Configuration):** Editor visits `wp-admin\u002Fpost.php` to save an `admin_form`.\n2.  **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).\n3.  **Entry Point 2 (Execution):** The attacker navigates to the frontend page where the \"Edit User\" form is rendered.\n4.  **Processing:** The form is submitted. The plugin calls `pre_update_value()` in `main\u002Ffields\u002Fclass-role.php` (inferred path).\n5.  **Vulnerable Logic:**\n    ```php\n    \u002F\u002F main\u002Ffields\u002Fclass-role.php (logic described in vulnerability)\n    public function pre_update_value($value, $post_id, $field) {\n        $role_options = $field['role_options']; \u002F\u002F Attacker controlled via configuration\n        if (in_array($value, $role_options)) {\n            return $value; \u002F\u002F Validates against form config, NOT WP capabilities\n        }\n    }\n    ```\n6.  **Sink 2:** The user's role is updated via `wp_update_user()` or `WP_User::set_role()`.\n\n## 4. Nonce Acquisition Strategy\nThe 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.\n\n1.  **Form Configuration Nonce:** When editing the `admin_form` in the dashboard, the standard WordPress `_wpnonce` for `post.php` is required.\n2.  **Frontend Form Nonce:** The frontend forms (ACF Frontend) typically localize a nonce.\n    *   **Action:** Look for `wp_localize_script` calls in the source.\n    *   **JS Variable:** Likely `frontend_admin` or `acf_frontend`.\n    *   **Key:** `nonce` or `ajax_nonce`.\n3.  **Acquisition Steps:**\n    *   Create a page with the form: `wp post create --post_type=page --post_status=publish --post_content='[acf_frontend_form form_id=\"XXX\"]'`.\n    *   Navigate to the page using `browser_navigate`.\n    *   Execute: `browser_eval(\"window.acf_frontend?.nonce\")` or check for hidden input `_acf_nonce`.\n\n## 5. Exploitation Strategy\n\n### Phase 1: Unauthenticated Editor Registration\n*   **Goal:** Register a new user with the \"Editor\" role.\n*   **Action:** Locate a public \"New User\" form created by the plugin. If none exists, find the shortcode and create one via WP-CLI.\n*   **Payload:** Submit the registration form, ensuring the `role` parameter (if hidden) is set to `editor`.\n\n### Phase 2: Form Configuration Manipulation\n*   **Goal:** Create\u002FEdit an \"Edit User\" form and allow it to assign the \"Administrator\" role.\n*   **Request:** `POST \u002Fwp-admin\u002Fpost.php`\n*   **Parameters:**\n    *   `action`: `editpost`\n    *   `post_ID`: The ID of the `admin_form`.\n    *   Find the ACF field key for `role_options`. It will likely look like `acf[field_xxxxxx]`.\n    *   Inject `administrator` into the array: `acf[field_xxxxxx][]=administrator`.\n\n### Phase 3: Privilege Escalation\n*   **Goal:** Use the manipulated form to escalate the Editor account to Administrator.\n*   **Request:** `POST` to the page containing the form (or `admin-ajax.php` if it's an AJAX form).\n*   **Parameters:**\n    *   `acf[field_role_key]`: `administrator`\n    *   `_acf_form`: Base64 encoded form settings.\n    *   `_acf_nonce`: Extracted from the frontend page.\n\n## 6. Test Data Setup\n1.  **Plugin Setup:** Ensure `acf-frontend-form-element` is active.\n2.  **Form Creation:** \n    *   Use WP-CLI to create an `admin_form` post: \n        `wp post create --post_type=admin_form --post_title=\"Escalator\" --post_status=publish`\n3.  **Target Page:** \n    *   Create a page to host the form:\n        `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\"]'`\n\n## 7. Expected Results\n*   Phase 2: The `admin_form` metadata should now contain `administrator` in the `role_options` list.\n*   Phase 3: The response should indicate a successful update (HTTP 200 or a redirect).\n*   The Editor user's role in the database should change from `editor` to `administrator`.\n\n## 8. Verification Steps\n1.  **Check User Role:** `wp user get \u003Cattacker_user_id> --field=roles`\n2.  **Confirm Admin Access:** Use the attacker's cookies to request `\u002Fwp-admin\u002Fsettings-general.php`. A successful response (200 OK) confirms administrative access.\n3.  **Inspect Form Meta:** `wp post primary-meta get \u003Cform_id> role_options` (to confirm the bypass worked).\n\n## 9. Alternative Approaches\n*   **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.\n*   **REST API:** Check if `wp-json\u002Facf-frontend\u002Fv1\u002Fforms` endpoints exist and allow form configuration updates without proper capability checks on the `role_options` field.\n*   **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.","gemini-3-flash-preview","2026-05-20 17:38:32","2026-05-20 17:39:30",{"type":38,"vulnerable_version":39,"fixed_version":11,"vulnerable_browse":40,"vulnerable_zip":41,"fixed_browse":42,"fixed_zip":43,"all_tags":44},"plugin","3.28.36","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Facf-frontend-form-element\u002Ftags\u002F3.28.36","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Facf-frontend-form-element.3.28.36.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Facf-frontend-form-element\u002Ftags\u002F3.29.1","https:\u002F\u002Fdownloads.wordpress.org\u002Fplugin\u002Facf-frontend-form-element.3.29.1.zip","https:\u002F\u002Fplugins.trac.wordpress.org\u002Fbrowser\u002Facf-frontend-form-element\u002Ftags"]