Gutenberg Blocks by Kadence Blocks <= 3.5.32 - Missing Authorization

This research plan outlines the technical steps to verify and exploit CVE-2026-2608, a Missing Authorization vulnerability in the Kadence Blocks plugin (versions <= 3.5.32).

---

1. Vulnerability Summary

The Kadence Blocks plugin registers several REST API endpoints to manage block settings, global styles, and AI-powered layout features. In affected versions, one or more of these endpoints uses an insufficiently restrictive permission_callback. Instead of requiring administrative capabilities (like manage_options), the endpoint only checks for the edit_posts capability. This allows Contributor-level users (who possess edit_posts) to perform administrative actions, such as modifying global plugin settings or site-wide block defaults.

2. Attack Vector Analysis

• Endpoint: /wp-json/kadence-blocks/v1/settings (inferred based on plugin architecture and patch history).
• HTTP Method: POST
• Authentication: Required (Contributor level or higher).
• Vulnerable Parameter: The JSON body containing setting keys and values (e.g., {"settings": { ... }}).
• Preconditions: The plugin must be active, and the attacker must have valid credentials for a Contributor account.

3. Code Flow (Inferred)

1. Registration: During rest_api_init, the plugin calls register_rest_route in a class like Kadence_Blocks_REST_Controller.
2. Weak Permission Check: The permission_callback for the settings route is likely set to current_user_can( 'edit_posts' ) or a similar wrapper function that validates the user can edit content but doesn't check for administrative management.
3. Action Sink: The callback function (e.g., update_settings) receives the REST request and passes the data directly to update_option( 'kadence_blocks_settings', ... ) after minimal sanitization, bypassing the capability check intended for site-wide configuration changes.

4. Nonce Acquisition Strategy

REST API requests in WordPress require a _wpnonce passed via the X-WP-Nonce header for authenticated sessions.

1. Identify Trigger: The Kadence Blocks plugin enqueues its REST configuration when the Gutenberg editor is loaded.
2. Setup Page: Use WP-CLI to ensure a Contributor can access the editor.

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

3. Navigate and Extract:
   • Use browser_navigate to login and go to /wp-admin/post-new.php.
   • Use browser_eval to extract the REST nonce from the WordPress core wpApiSettings object or the Kadence-specific localized object.
   • JavaScript Variable: window.wpApiSettings.nonce or window.kadence_blocks_params.nonce.

5. Exploitation Strategy

The goal is to modify a global plugin setting that a Contributor should not be able to touch.

Step 1: Obtain the Nonce
Navigate to the post editor as a Contributor and run:
const restNonce = window.wpApiSettings.nonce;

Step 2: Send the Malicious REST Request
Use the http_request tool to send a POST request to update global settings. We will attempt to modify the is_live_preview or ai_api_key (if available) or simply toggle a global feature.

• URL: http://localhost:8080/wp-json/kadence-blocks/v1/settings
• Method: POST
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Payload:

  {
    "settings": {
      "show_pro": true,
      "is_live_preview": false,
      "some_restricted_flag": "malicious_value"
    }
  }
  

6. Test Data Setup

1. Install Plugin: Ensure Kadence Blocks v3.5.32 is installed.
2. Create User:

   wp user create tester tester@example.com --role=contributor --user_pass=tester123
   

3. Capture Initial State:

   wp option get kadence_blocks_settings
   

7. Expected Results

• Vulnerable Version: The server returns 200 OK or 201 Created. The response body contains the updated settings object.
• Patched Version: The server returns 403 Forbidden with a message like "Sorry, you are not allowed to do that." because the permission_callback now requires manage_options.

8. Verification Steps

After the HTTP request, verify the change in the database using WP-CLI:

# Check if the global option was actually updated
wp option get kadence_blocks_settings

If the output reflects the values sent in the http_request payload, the unauthorized access is confirmed.

9. Alternative Approaches

If the /settings endpoint is not the target, analyze other Kadence REST namespaces:

1. Query Loop/Post Grid: kadence-blocks/v1/post-grid-query - Check if a Contributor can query private posts or sensitive metadata by manipulating query arguments.
2. AI Templates: kadence-blocks/v1/ai-get-templates - Check if a Contributor can trigger remote API calls or update AI library credentials.
3. Search Pattern: Run this in the plugin directory to find potential weak permission callbacks:

   grep -rn "permission_callback" . -A 5 | grep "edit_posts"
   

   Any result that points to a "save" or "update" action is a high-probability target.