Exploitation Research Plan - CVE-2026-1582

1. Vulnerability Summary

The WP All Export plugin (up to version 1.4.14) is vulnerable to Sensitive Information Exposure due to a PHP type juggling vulnerability in its export download authentication logic. The plugin uses a loose comparison (==) instead of a strict comparison (===) when validating a security token provided in the URL against a generated MD5 hash.

In actions/wp_loaded.php, the plugin validates the security_token or export_hash by comparing it to the first 16 characters of md5($cron_job_key . $export_id). If the resulting MD5 hash starts with "0e" followed only by numbers (a "magic hash"), PHP interprets both the hash and an attacker-provided magic hash (e.g., 0e12345...) as the float 0.0, bypassing the authentication check. This allows unauthenticated attackers to download export files containing sensitive site data.

2. Attack Vector Analysis

• Endpoint: The main WordPress root (/) triggers the wp_loaded hook.
• Parameters:
  • action: Must be get_data or get_bundle.
  • export_id: The ID of the export to download (e.g., 1).
  • security_token (or export_hash): The attacker-provided payload.
• Authentication: Unauthenticated.
• Preconditions:
  • An export must exist.
  • The cron_job_key concatenated with the export_id must result in an MD5 hash that starts with 0e followed by digits (within the first 16 characters).

3. Code Flow

1. Entry Point: actions/wp_loaded.php defines pmxe_wp_loaded(), which is hooked to wp_loaded.
2. Input Capture:
   • The function checks if ( ! empty($_GET['action']) && ! empty($_GET['export_id']) && (!empty($_GET['export_hash']) || !empty($_GET['security_token']))).
   • It retrieves $securityToken from $_GET['security_token'] or $_GET['export_hash'].
3. Vulnerable Logic (Line ~16):

   $cron_job_key = PMXE_Plugin::getInstance()->getOption('cron_job_key');
   if ( $securityToken == substr(md5($cron_job_key . $_GET['export_id']), 0, 16) )
   

4. Sink: If the comparison returns true, the code proceeds to locate the export file path and either redirects the user to the file (wp_redirect($fileurl)) or serves it via readfile($filepath).

4. Nonce Acquisition Strategy

No nonce is required. The pmxe_wp_loaded function executes early in the WordPress lifecycle and does not perform any nonce or capability checks, relying solely on the vulnerable hash comparison for "security."

5. Exploitation Strategy

To demonstrate the vulnerability in an automated test environment, we must ensure the cron_job_key and export_id result in a magic hash.

Step-by-Step Plan:

1. Identify/Set cron_job_key: Use WP-CLI to find a key that, when combined with export_id=1, produces an MD5 starting with 0e followed by digits.
   • Example: md5("7313010" . "1") = 0e71630....
   • We will set the plugin's cron_job_key to 7313010.
2. Create an Export: Use WP-CLI to create at least one export record so ID 1 exists and has a file associated with it.
3. Execute Attack: Send a GET request to the site root with action=get_data, export_id=1, and security_token=0e000000000000000000000000000000.
4. Verify Bypass: The server should respond with a 302 Redirect to the export file or a 200 OK containing the file data, rather than a 403 "Export hash is not valid."

6. Test Data Setup

1. Install Plugin: Ensure wp-all-export v1.4.14 is active.
2. Configure Secret Key:

   # Set a key that produces a magic hash for ID 1
   # md5("7313010" . "1") starts with 0e71... (digits only)
   wp eval 'PMXE_Plugin::getInstance()->updateOption("cron_job_key", "7313010");'
   

3. Create Export Data:
   • Create a dummy post or user to export.
   • Create an export record in the database.

   # Use wp eval to create an export record for ID 1
   wp eval '
   $export = new PMXE_Export_Record();
   $export->set(array(
       "id" => 1,
       "options" => array(
           "filepath" => "wp-content/uploads/wp-all-export/exports/test.csv",
           "export_to" => "csv"
       ),
       "attch_id" => 0
   ))->save();
   mkdir(ABSPATH . "wp-content/uploads/wp-all-export/exports/", 0777, true);
   file_put_contents(ABSPATH . "wp-content/uploads/wp-all-export/exports/test.csv", "id,secret_data\n1,vulnerable_info");
   '
   

7. Expected Results

• Request: GET /?action=get_data&export_id=1&security_token=0e11111111111111
• Response: HTTP 302 (Redirect to the CSV file) or HTTP 200 (File content).
• Failure Case (Strict Comparison): If the comparison were ===, the response would be HTTP 403 with the message {"status":403,"message":"Export hash is not valid."}.

8. Verification Steps

1. Check Response Code: Ensure the response is not a 403 Forbidden.
2. Check Content: If the response is a redirect, follow it and verify the CSV content matches the dummy data created in Step 6.
3. Confirm PHP version: Type juggling behavior is most prominent in PHP 7.x, though it persists in PHP 8.x for string-to-string comparisons like this one.

9. Alternative Approaches

If setting the cron_job_key via updateOption fails, the agent can:

1. Manually insert the option into the wp_options table using wp db query.
2. Brute-force the export_id (e.g., from 1 to 5000) while keeping a fixed security_token=0e123... until one hits a magic hash collision with the existing cron_job_key. This is more "realistic" but slower.
3. If the export file is served via wp_redirect, the agent must ensure it captures the Location header to verify access to the actual file.