Download Media Library <= 0.2.1 - Unauthenticated Sensitive Information Exposure

As source files for the Download Media Library (<= 0.2.1) plugin are not provided, this research plan is based on the vulnerability description (Unauthenticated Sensitive Information Exposure) and common architectural patterns in WordPress "download" plugins. The plan guides the automated agent to identify the specific exposure point and exploit it.

1. Vulnerability Summary

The Download Media Library plugin is designed to facilitate bulk downloading of media files. The vulnerability (CVE-2025-62114) is likely caused by an unauthenticated AJAX or REST API endpoint that returns sensitive data (such as user details, site configuration, or internal file paths) without performing capability checks (current_user_can) or authentication. Because it is "Unauthenticated Information Exposure," the entry point is almost certainly a wp_ajax_nopriv_* hook or a REST route with a permission_callback that returns __return_true.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php (for AJAX) or wp-json/ (for REST API).
• Action/Route (Inferred): Likely actions include dml_download_all, dml_export_data, or dml_get_media_list.
• Parameter: A nonce (if required) and possibly parameters like type, limit, or id.
• Authentication: None required (unauthenticated).

3. Code Flow (Target Patterns)

The researcher agent must locate the following flow in the plugin directory (/wp-content/plugins/download-media-library/):

1. Entry Point Identification:
   • Search for unauthenticated AJAX: grep -rn "wp_ajax_nopriv_" .
   • Search for REST routes: grep -rn "register_rest_route" .
2. Logic Trace:
   • Find the function callback associated with the unauthenticated hook.
   • Look for sensitive sinks:
     • $wpdb->get_results("SELECT ... FROM $wpdb->users") (User exposure).
     • get_options() without filtering (Config/Secrets exposure).
     • readfile() or file_get_contents() with user-controlled input (File exposure).
     • Direct echo or wp_send_json() of sensitive internal arrays.

4. Nonce Acquisition Strategy

If the unauthenticated endpoint requires a nonce, follow these steps to extract it:

1. Find Nonce Creation: Search for wp_create_nonce in the plugin code to find the action name.
2. Find Localization: Search for wp_localize_script to see which JS variable holds the nonce.
   • Guess (Inferred): window.dml_vars?.nonce or window.download_media_library_ajax?.nonce.
3. Identify Trigger: Look for add_shortcode to find what triggers the script/nonce to load on the frontend.
4. Extraction Procedure:
   • Create a page containing the plugin's shortcode:
     wp post create --post_type=page --post_status=publish --post_content='[dml_shortcode_name]' (Replace with actual name found).
   • Navigate to the new page using browser_navigate.
   • Execute JS to retrieve the nonce:
     browser_eval("window.DML_OBJECT_NAME.nonce_key") (Replace with actual identifiers).

5. Exploitation Strategy

Once the endpoint and nonce are identified, the agent will perform the following:

HTTP Request (Example for AJAX-based exposure):

• Method: POST
• URL: http://<target>/wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body: action=dml_vulnerable_action&nonce=EXTRACTED_NONCE&other_param=value

HTTP Request (Example for REST-based exposure):

• Method: GET
• URL: http://<target>/wp-json/download-media-library/v1/sensitive-data?_wpnonce=EXTRACTED_NONCE

6. Test Data Setup

To ensure the vulnerability is reproducible:

1. Media Upload: Upload at least 3 files to the media library to ensure the plugin has data to "process."
   wp media import /path/to/image.jpg --title="Secret File"
2. User Creation: Create a dummy user to see if their data (email/hash) is exposed.
   wp user create victim victim@example.com --role=author
3. Shortcode Page: (If a nonce is needed) Create the page identified in Section 4.

7. Expected Results

• Successful Exploitation: The HTTP response body (JSON or raw text) contains sensitive information not normally available to guests.
• Target Data: Look for keys like user_login, user_email, db_password, abspath, or sensitive file contents in the response.

8. Verification Steps

After the http_request tool receives the data, confirm its validity:

1. If user data is returned, check if the emails match the output of:
   wp user list --fields=user_email
2. If file paths are returned, verify the files exist:
   ls -la [PATH_FROM_EXPLOIT]
3. If configuration data is leaked, verify against wp option get [OPTION_NAME].

9. Alternative Approaches

• Path Traversal: If the "Information Exposure" involves file downloads, try to request /etc/passwd or wp-config.php using parameters like file=../../../../wp-config.php.
• SQL Injection: If the information exposure happens via a database query, check if any parameters used in the query are unsanitized, which could lead to a full database dump.
• Debug Logs: Check if the plugin accidentally exposes a path to a custom log file containing sensitive transaction data.