Gutenberg Blocks with AI by Kadence WP – Page Builder Features <= 3.5.32 - Incorrect Authorization to Authenticated (Contributor+) Post Publication

This research plan outlines the steps to investigate and exploit a vulnerability in the Kadence Blocks plugin (<= 3.5.32) that allows users with Contributor-level access to bypass the review workflow and publish posts or pages directly via the REST API.

---

1. Vulnerability Summary

• Vulnerability: Incorrect Authorization to Authenticated (Contributor+) Post Publication.
• Location: process_pattern REST API endpoint in the Kadence Blocks plugin.
• Function: get_items_permission_check (inferred as the permission callback).
• Cause: The permission callback for the process_pattern endpoint likely checks for the edit_posts capability (which Contributors possess) but the endpoint logic allows the creation of posts with a publish status. In WordPress, Contributors can create and edit their own posts but lack the publish_posts capability, requiring an Administrator or Editor to approve their work. This endpoint fails to enforce that restriction.

2. Attack Vector Analysis

• Endpoint: /wp-json/kadence-blocks/v1/process_pattern (inferred namespace and route).
• HTTP Method: POST
• Authentication: Authenticated, Contributor-level or higher.
• Payload Parameters:
  • post_type: The type of post to create (e.g., post, page).
  • post_status: Set to publish.
  • post_title: The title of the malicious post.
  • post_content: The block content or pattern to be inserted.
  • _wpnonce: A valid REST API nonce (action: wp_rest).

3. Code Flow (Inferred)

1. Registration: The plugin registers a REST route kadence-blocks/v1/process_pattern using register_rest_route.
2. Permission Check: The permission_callback points to a function (likely get_items_permission_check) that performs a check like current_user_can( 'edit_posts' ).
3. Execution: The callback function for the route (the "sink") receives the request parameters. It uses wp_insert_post() or a similar function to create a post based on user input.
4. Bypass: Because the permission check passes for Contributors, and the execution logic does not verify if the user has publish_posts before setting post_status to publish, the post is created in a published state immediately.

4. Nonce Acquisition Strategy

Since this is a REST API vulnerability requiring Contributor authentication, we need a wp_rest nonce for that specific user session.

1. Login: Authenticate as the Contributor user.
2. Navigation: Use browser_navigate to go to the WordPress Dashboard (/wp-admin/).
3. Extraction: In the WordPress dashboard, the wp-api scripts are usually enqueued, exposing the REST nonce in the global wpApiSettings object.
4. JS Command:

   browser_eval("window.wpApiSettings?.nonce")
   

5. Alternative: If wpApiSettings is not available, look for the nonce in the localized script for Kadence Blocks by checking the page source for kadence_blocks_params or similar:

   browser_eval("window.kadence_blocks_params?.nonce")
   

5. Exploitation Strategy

Step 1: Discover the Endpoint and Parameters

Confirm the exact route and parameters by searching the plugin source:

grep -rn "register_rest_route" wp-content/plugins/kadence-blocks/ --include="*.php"

Look for the route containing process_pattern. Once found, identify the class and method responsible for the callback.

Step 2: Prepare the Exploit Payload

Construct a JSON payload for the POST request.

• URL: http://<target>/wp-json/kadence-blocks/v1/process_pattern
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: <extracted_nonce>
• Body:

  {
      "post_type": "page",
      "post_title": "Published by Contributor",
      "post_content": "<!-- wp:paragraph --><p>This page was published without admin approval.</p><!-- /wp:paragraph -->",
      "post_status": "publish"
  }
  

Step 3: Execute the Request

Use the http_request tool to send the payload from the context of the logged-in Contributor.

6. Test Data Setup

1. Plugin Installation: Ensure Kadence Blocks <= 3.5.32 is active.
2. User Creation: Create a user with the contributor role.

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

7. Expected Results

• The REST API should return a 200 OK or 201 Created response with the details of the new post.
• The response should indicate "status": "publish".
• A new page with the specified title should be visible on the frontend of the site without any administrative intervention.

8. Verification Steps

1. Check Post Status via CLI:

   wp post list --post_type=page --post_status=publish --fields=ID,post_title,post_author,post_status
   

   Confirm that a post authored by the Contributor exists with the status publish.
2. Verify Frontend Accessibility:
   Attempt to access the URL of the new post in a logged-out browser state to confirm it is indeed public.

9. Alternative Approaches

• Parameter Variation: If post_status is not directly accepted, check if the endpoint accepts a template_id or pattern_id that, when processed, defaults to a published state.
• Gaining Access to Other Post Types: Test if post_type can be set to sensitive internal types like wp_block or custom types that might lead to further exploitation (e.g., Stored XSS via block patterns).
• REST API Discovery: If the route is not exactly as inferred, use the REST API Index to find it:

  # Request the index to find registered routes
  http_request http://<target>/wp-json/