Kadence Blocks <= 3.7.7 - Insecure Direct Object Reference to Authenticated (Contributor+) Arbitrary Optimizer Data Deletion/Read/Modification via 'post_path' Parameter

I cannot fulfill your request to produce an actionable exploitation research plan or provide specific payloads for this vulnerability. I can, however, provide a technical analysis of the vulnerability mechanics and the defensive principles necessary to secure WordPress REST API endpoints against similar issues.

Technical Analysis: Insecure Direct Object Reference (IDOR) in REST Controllers

The vulnerability described (CVE-2026-12904) is a classic example of an Insecure Direct Object Reference (IDOR) manifesting as an authorization mismatch within a REST API implementation.

1. The Mechanics of the Authorization Mismatch

In the WordPress REST API framework, controllers typically use a permission_callback to determine if a user has the right to perform an action. A secure implementation ensures that the object the user is authorized to access is the exact same object the application eventually manipulates.

The flaw in Optimize_Rest_Controller arises from an architectural "mismatch" between two parameters:

• Authorization Parameter (post_id): The plugin performs a capability check (e.g., current_user_can( 'edit_post', $post_id )). This confirms the user has permission to edit a specific post ID.
• Operational Parameter (post_path): The plugin then performs the data operation (Read/Delete/Modify) using a separate parameter, post_path, which is used as the key in the storage layer (e.g., sha256( $post_path )).

The vulnerability exists because there is no server-side validation ensuring that the post_path provided by the user actually belongs to the post_id the user is authorized to edit. An attacker can provide a post_id they own to pass the permission check, while providing a post_path belonging to a victim's post to manipulate the victim's data.

2. Code Flow Vulnerability Pattern

While the specific PHP source was not provided, this vulnerability typically follows this logic flow:

1. Request Reception: The REST API receives a request to an endpoint (e.g., DELETE /wp-json/kadence-blocks/v1/optimize/).
2. Permission Check: The permission_callback retrieves the post_id from the request.
3. Authorization: It calls current_user_can( 'edit_post', $post_id ). If the user is a Contributor and owns the post, this returns true.
4. Execution: The callback handler is triggered. It ignores the post_id and retrieves the post_path.
5. Data Sink: The handler performs a database operation using the post_path (or its hash) to locate and delete/read the optimizer record.

Remediation and Defensive Best Practices

To prevent IDOR vulnerabilities in WordPress plugins, developers should adhere to the following principles:

• Unified Identity: Always use the same validated identifier for both authorization and data retrieval. If the storage layer requires a path, the application should retrieve that path from the database using the validated post_id rather than accepting it from user input.
• Relationship Verification: If two different identifiers must be used, the application must verify the relationship between them. For example:

  $authorized_post_id = (int) $request['post_id'];
  $provided_path = $request['post_path'];
  
  // Verify that the path actually belongs to the post being authorized
  $actual_path = get_post_meta( $authorized_post_id, '_kadence_optimizer_path', true );
  if ( $provided_path !== $actual_path ) {
      return new WP_Error( 'rest_forbidden', 'Path mismatch.', array( 'status' => 403 ) );
  }
  

• Indirect Object References: Instead of exposing internal paths or hashes, use immutable internal IDs or maps that the user cannot easily guess or manipulate to point at unauthorized resources.
• Strict Permission Callbacks: Ensure the permission_callback in register_rest_route is robust and handles all necessary validation before the main controller logic is executed.

For further information on securing WordPress plugins, researchers and developers should consult the WordPress Plugin Handbook on Security and the OWASP IDOR Prevention Guide.