Exploitation Research Plan: CVE-2025-12640 (Folders Plugin)

1. Vulnerability Summary

The Folders plugin (up to v3.1.5) contains a missing object-level authorization (IDOR) vulnerability in the handle_folders_file_upload() function. While the plugin may check if a user has a general capability to upload files (e.g., upload_files), it fails to verify if the authenticated user has permission to modify the specific media attachment ID provided in the request. This allows an attacker with Author level permissions or higher to replace media files owned by other users, including Administrators.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: folders_file_upload (inferred from function name)
• HTTP Method: POST
• Authentication: Required (Author level or higher).
• Vulnerable Parameter: attachment_id (or similar ID field) and the file / async-upload payload.
• Preconditions:
  • An attacker must have credentials for an account with at least Author role.
  • The attacker must know the attachment ID of the media file they wish to replace.

3. Code Flow (Inferred)

1. Registration: The plugin registers an AJAX handler:
   add_action('wp_ajax_folders_file_upload', array($this, 'handle_folders_file_upload'));
2. Handler Entry: The handle_folders_file_upload() function is called.
3. Basic Check: The function likely calls check_ajax_referer() to validate a CSRF nonce and current_user_can('upload_files').
4. Vulnerable Logic: The function accepts an attachment_id from $_POST.
5. The Sink: It uses the provided ID to locate the file path on disk and proceeds to overwrite the existing file with the newly uploaded file content using move_uploaded_file() or WP_Filesystem, without checking if current_user_can('edit_post', $attachment_id).

4. Nonce Acquisition Strategy

The folders_file_upload action likely requires a nonce. In the Folders plugin, nonces are usually localized for the media library interface.

1. Identify the Script: Grep the plugin for wp_localize_script to find where the nonce is passed to the frontend.
   • Command: grep -rn "wp_localize_script" wp-content/plugins/folders/
2. Locate Nonce Key: Look for a key related to "upload" or "nonce" (e.g., folders_nonce or upload_nonce).
3. Extraction via Browser:
   • The execution agent should log in as the Author user.
   • Navigate to the Media Library: browser_navigate("http://localhost:8080/wp-admin/upload.php").
   • Use browser_eval to extract the nonce.
   • Example (inferred): browser_eval("window.folders_data?.nonce") or browser_eval("window.folders_settings?.upload_nonce").

5. Exploitation Strategy

The goal is to replace a sensitive file (e.g., company-logo.png uploaded by an Admin) with a malicious or spoofed image.

1. Preparation: Log in as the Author user using the http_request tool to obtain session cookies.
2. Information Gathering: Identify the attachment_id of a target image uploaded by the Admin (via wp media list in the CLI).
3. Craft the Request:
   • URL: http://localhost:8080/wp-admin/admin-ajax.php
   • Headers: Content-Type: multipart/form-data
   • Parameters:
     • action: folders_file_upload (inferred)
     • nonce: [EXTRACTED_NONCE]
     • attachment_id: [TARGET_ID]
     • file: (The new image file binary)
4. Execute: Send the POST request using the http_request tool.

6. Test Data Setup

1. Target User: Use the existing admin user.
2. Attacker User: Create an Author user:
   • wp user create attacker attacker@example.com --role=author --user_pass=password123
3. Target Media: As admin, upload a specific file:
   • wp media import /path/to/original-image.png --title="Admin Secret Image" --user=admin
4. Note the ID: Get the ID of the new media:
   • wp post list --post_type=attachment

7. Expected Results

• The HTTP response should indicate success (e.g., {"success": true} or a 200 OK with file metadata).
• The file on the server associated with the Admin's attachment_id will now contain the data from the Author's uploaded file.
• The original image is overwritten.

8. Verification Steps

1. Check File Content: Use WP-CLI to find the path of the target attachment and verify its integrity.
   • wp post get [ID] --field=guid (to get the URL)
2. Verify Overwrite: Check the file on disk to see if it matches the attacker's payload rather than the original.
   • md5sum wp-content/uploads/YYYY/MM/original-image.png
3. Confirm Permissions: Use wp post get [ID] to confirm the post_author is still the Admin (ID 1), proving an Author modified an Admin's resource.

9. Alternative Approaches

• Search for Other Actions: If folders_file_upload is incorrect, grep for the function name handle_folders_file_upload in the plugin directory to find the actual wp_ajax_ string.
• REST API: Check if the plugin registers any REST routes in rest_api_init hooks that map to the same file upload logic, as these may also lack the permission_callback object check.
• Directory Traversal: If the attachment_id logic involves building a path, test if the ID can be manipulated or if other path parameters allow overwriting files outside the uploads directory (though less likely for this specific CVE).