Exploitation Research Plan - CVE-2025-62135

1. Vulnerability Summary

The Responsive Block Control plugin (<= 1.3.0) for WordPress is vulnerable to Authenticated (Contributor+) Stored Cross-Site Scripting. The plugin allows users to control the visibility of Gutenberg blocks based on device width. This is achieved by adding custom attributes to blocks. The vulnerability exists because these attributes are not properly sanitized upon being saved in the post content and are subsequently rendered on the frontend without sufficient escaping. An attacker with "Contributor" privileges (who can create and edit posts) can inject malicious JavaScript into these attributes.

2. Attack Vector Analysis

• Authentication Level: Contributor or higher (requires edit_posts capability).
• Vulnerable Endpoint: WordPress REST API post update/creation endpoint (/wp-json/wp/v2/posts).
• Vulnerable Parameter: content (specifically, the JSON-encoded attributes within Gutenberg block comments).
• Payload Location: Inside a block attribute managed by the plugin, such as a visibility setting or a custom CSS class field.
• Preconditions: The plugin must be active. The attacker must have credentials for a Contributor-level account.

3. Code Flow (Inferred)

1. Input: A Contributor saves a post containing a Gutenberg block (e.g., a Paragraph block) with malicious attributes.
2. Storage: WordPress saves the block in the wp_posts table. The attributes are stored within the HTML comment delimiters, e.g., <!-- wp:paragraph {"responsive_control_attr": "PAYLOAD"} -->.
3. Processing: When the post is viewed, the plugin uses the render_block hook (inferred) to modify the block's HTML output based on the stored attributes.
4. Sink: The plugin retrieves the attribute value and appends it to the block's wrapper element (likely as a CSS class or a style attribute) using string concatenation or printf without applying esc_attr() or esc_html().
5. Execution: The payload is rendered in the victim's browser, leading to XSS.

4. Nonce Acquisition Strategy

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

1. Role Creation: Use WP-CLI to create a contributor user.
2. Login: Log in to the WordPress admin dashboard as the contributor.
3. Navigation: Use browser_navigate to go to the "Add New Post" page: /wp-admin/post-new.php.
4. Extraction: Execute browser_eval to extract the REST nonce from the global wpApiSettings object.
   • JavaScript: window.wpApiSettings.nonce
5. Alternative: If using the classic editor/legacy AJAX, extract the nonce from document.querySelector('#_wpnonce').value.

5. Exploitation Strategy

The goal is to inject a payload into a block attribute that the plugin processes and outputs.

• Step 1: Obtain the REST API nonce for the Contributor user.
• Step 2: Construct a REST API request to create a new post. The content will include a Gutenberg block with a malicious attribute.
• Target Attribute (Inferred): The plugin likely uses attributes like responsiveVisibility or devices. We will target a generic attribute and a predicted plugin-specific one.
• Payload: "><script>alert(document.domain)</script>
• HTTP Request:

  POST /wp-json/wp/v2/posts HTTP/1.1
  Host: localhost:8888
  Content-Type: application/json
  X-WP-Nonce: [EXTRACTED_NONCE]
  
  {
    "title": "XSS Test",
    "status": "draft",
    "content": "<!-- wp:paragraph {\"responsiveControl\": \"\\\" onmouseover=\\\"alert(1)\\\"\"} -->\n<p>Hover over this text.</p>\n<!-- /wp:paragraph -->"
  }
  

• Step 3: Retrieve the id of the created post from the JSON response.
• Step 4: Navigate to the post preview or view the post (if published) to trigger the XSS.

6. Test Data Setup

1. Install Plugin: wp plugin install responsive-block-control --version=1.3.0 --activate
2. Create User: wp user create attacker attacker@example.com --role=contributor --user_pass=password123
3. Identify Attributes: To be precise, first create a post manually in the UI, toggle a "Responsive Block Control" setting, and run wp post get [ID] --field=post_content to see the exact attribute name used by the plugin. (e.g., devices).

7. Expected Results

• The HTTP request should return a 201 Created status code.
• The post_content in the database should contain the raw payload.
• When viewing the post frontend, the HTML of the block should look like:
  <div class="..." " onmouseover="alert(1)">...</div> or similar, indicating attribute injection.
• A browser alert box should appear if a script tag was used or an event handler was triggered.

8. Verification Steps

1. Check Database: wp db query "SELECT post_content FROM wp_posts WHERE post_title='XSS Test'"
2. Verify Rendering: Use the http_request tool to GET the post URL and check if the payload is present in the response body unescaped.
   • Check if alert(1) exists within the HTML.
   • Confirm the absence of esc_attr (e.g., " should not be ").

9. Alternative Approaches

• Block Variations: Try different Gutenberg blocks (Heading, Image, List) as the plugin might handle different block types with different code paths.
• Meta-based Injection: If the plugin uses post meta instead of block attributes for certain settings, attempt to update post meta via the REST API or admin-ajax.php.
• Classic Editor: If the site uses the Classic Editor, the plugin might use shortcodes. Test injecting the payload into shortcode attributes: [shortcode attr='"><script>alert(1)</script>'].