Research Plan: CVE-2026-56009 - Bricksable for Bricks Builder Stored XSS

1. Vulnerability Summary

The Bricksable for Bricks Builder plugin (<= 1.6.83) is vulnerable to Authenticated Stored Cross-Site Scripting (XSS). The plugin registers several custom elements for the Bricks Page Builder. These elements (e.g., Multi Heading, Icon List, Card, Back To Top) define various input controls (text, textarea, etc.) in their set_controls() methods.

The vulnerability exists because the plugin fails to sanitize these inputs when they are saved via the Bricks Builder and, more importantly, fails to escape the values when they are rendered in the render() method of the element classes. An attacker with Author level access or higher can use the Bricks Builder to insert a Bricksable element and inject malicious JavaScript into one of the element's settings. This script is then stored in the post's metadata and executes in the context of any user (including Administrators) who views the affected page or opens it in the builder.

2. Attack Vector Analysis

• Target Endpoint: WordPress AJAX handler admin-ajax.php.
• Action: bricks_save_post (The standard Bricks Builder save action).
• Vulnerable Parameters: The elements JSON object within the POST body, specifically within the settings of Bricksable elements.
• Authentication: Required. Role: Author or higher (any role capable of using the Bricks Builder to edit a post).
• Preconditions:
  • Bricks Builder plugin must be active.
  • Bricksable for Bricks Builder plugin must be active.
  • The attacker must have permissions to edit a post/page using the Bricks Builder.

3. Code Flow

1. Definition: Elements like Bricksable_Multi_Heading (in includes/elements/multi-heading/element-multi-heading.php) register controls. For example, the multi_heading_item repeater contains a text field:

   'text' => array(
       'type'           => 'text',
       'hasDynamicData' => 'text',
   ),
   

2. Storage: When a user saves a page in Bricks, the element's settings (including the text field) are sent via the bricks_save_post AJAX action and stored as JSON in the _bricks_page_content post meta.
3. Rendering (The Sink): When the page is viewed, Bricks calls the render() method of the element class. Although the render() methods are truncated in the provided source, the vulnerability description confirms that these settings are output without proper escaping (e.g., using esc_html() or wp_kses()).
4. Execution: The stored script is rendered directly into the HTML of the page and executed by the victim's browser.

4. Nonce Acquisition Strategy

To exploit bricks_save_post, a valid bricks-nonce is required. This nonce is tied to the Bricks Builder session.

1. Setup: The PoC agent should create a post and ensure it is "Bricks-enabled".
2. Navigate: Use the browser_navigate tool to go to the Bricks Builder interface for that post:
   http://<wp-url>/wp-admin/post.php?post=<POST_ID>&bricks=run
3. Extract: Use the browser_eval tool to extract the nonce and current page data from the global bricksData object:

   // The nonce is typically stored here
   const nonce = window.bricksData?.nonce;
   // We also need the current elements structure to ensure a valid save request
   const pageData = window.bricksData?.pageData;
   return { nonce, pageData };
   

5. Exploitation Strategy

The goal is to update a post's content with a malicious ba-multi-heading element.

Step-by-Step Plan:

1. Login: Authenticate as an Author user.
2. Find Post: Identify a post ID owned by the Author or create a new one.
3. Get Nonce: Navigate to the Bricks Builder page for that ID and extract bricksData.nonce.
4. Construct Payload: Create a JSON structure for a ba-multi-heading element where the text field contains the XSS payload.

   [
     {
       "name": "ba-multi-heading",
       "settings": {
         "multi_heading_item": [
           {
             "text": "Normal Title <script>alert(document.domain)</script>"
           }
         ]
       }
     }
   ]
   

5. Execute Injection: Send a POST request to admin-ajax.php.
   • URL: http://<wp-url>/wp-admin/admin-ajax.php
   • Content-Type: application/x-www-form-urlencoded
   • Body:

     action=bricks_save_post
     postId=<POST_ID>
     nonce=<EXTRACTED_NONCE>
     elements=<URL_ENCODED_JSON_PAYLOAD>
     

6. Verify: Navigate to the frontend URL of the post and check if the alert triggers.

6. Test Data Setup

1. User: Create a user with the author role.
2. Post: Create a post (e.g., ID 123) and set its post_status to publish.
3. Bricks Initialization: Ensure the post is set to use Bricks. This can be done by editing it once in the builder or setting post meta _bricks_editor_mode to true.

7. Expected Results

• The bricks_save_post request should return a success status (usually {"success": true}).
• When viewing the post frontend, the HTML source should contain the raw <script>alert(document.domain)</script> tag within the ba-multi-heading element container.
• The browser should execute the script.

8. Verification Steps

1. HTTP Verification: Observe the response from the frontend request to ensure the payload is present in the HTML.
2. Database Verification (CLI):

   wp post meta get <POST_ID> _bricks_page_content
   

   Check if the JSON in the metadata contains the injected script.

9. Alternative Approaches

If Multi Heading is patched or difficult to target, try other Bricksable elements identified in the source:

• Icon List (ba-icon-list): Inject into items -> title.
• Card (ba-card): Inject into the badge control.
• Content Toggle (ba-content-toggle): Inject into contentToggleItem -> label or content.
• Back To Top (ba-back-to-top): Inject into the text control.

The exploitation mechanism (Bricks AJAX save) remains the same for all these elements.