The Plus Addons for Elementor – Addons for Elementor, Page Templates, Widgets, Mega Menu, WooCommerce <= 6.4.11 - Authenticated (Contributor+) Stored Cross-Site Scripting

This research plan outlines the technical requirements and steps to demonstrate a Stored Cross-Site Scripting (XSS) vulnerability in "The Plus Addons for Elementor" (versions <= 6.4.11). This vulnerability allows Contributor-level users to inject malicious scripts into pages, which then execute in the context of any user (including Administrators) viewing those pages.

1. Vulnerability Summary

• Vulnerability Name: The Plus Addons for Elementor Stored XSS
• Vulnerability Type: Improper Neutralization of Input During Web Page Generation (Stored XSS)
• Vulnerability Component: Various widgets and the "Plus Extra Attributes" feature.
• Root Cause: The plugin fails to sanitize user-provided input in widget settings (such as IDs, classes, or custom data attributes) and subsequently fails to escape this data when rendering the widget on the frontend using functions like echo instead of esc_attr().
• Affected Versions: <= 6.4.11

2. Attack Vector Analysis

• Endpoint: WordPress REST API (Elementor Editor endpoint) or the standard Post Save mechanism.
• Action/Hook: wp_ajax_elementor_ajax or REST routes handled by Elementor's Editor class.
• Vulnerable Parameter: post_content (within the JSON-encoded settings of a specific "Plus" widget or extra attribute).
• Authentication: Contributor-level access (or higher) is required to edit posts and access the Elementor editor.
• Preconditions: The "The Plus Addons for Elementor" plugin must be active, and the Contributor must have permission to edit the specific post/page.

3. Code Flow (Inferred)

1. Input: A Contributor user opens the Elementor editor for a post and adds a widget from "The Plus Addons" (e.g., Heading, Button, or any widget with Plus Extra Attributes enabled).
2. Storage: The user enters a payload (e.g., "><script>alert(1)</script>) into a setting field like "Custom ID" or a "Custom Attribute". Elementor sends this data via a REST API request to save the post metadata.
3. Processing: The plugin saves these settings into the _elementor_data post meta without sanitization.
4. Output (Sink): When a user views the post, Elementor triggers the render() method of the widget class.
5. Vulnerability: Inside the render() method (likely in includes/widgets/ or via a filter in modules/), the plugin retrieves the custom attribute and outputs it directly into the HTML:

   // Example of vulnerable code pattern
   $id = $settings['plus_extra_id']; 
   echo '<div id="' . $id . '">'; // No esc_attr() here
   

4. Nonce Acquisition Strategy

Elementor exploitation requires the wp_rest nonce for authenticated REST API calls.

1. Identify the Trigger: Elementor's editor needs to be active.
2. Create Test Content: Create a page and set it to be edited with Elementor.
   • wp post create --post_type=page --post_status=publish --post_title="XSS Research" --post_content=''
3. Extract Nonce:
   • Navigate to the WordPress dashboard and find the "Edit with Elementor" link for the newly created page.
   • Navigate to that editor URL using browser_navigate.
   • Use browser_eval to extract the REST nonce from the Elementor configuration object:

     // Elementor stores the REST nonce in the following location
     window.elementorCommonConfig?.api_nonce;
     

   • If a plugin-specific AJAX nonce is required (for non-Elementor actions), look for:

     window.theplus_ajax_nonce; // Inferred from common plugin JS localization
     

5. Exploitation Strategy

The goal is to inject a script into a widget setting that is rendered as an HTML attribute.

Step-by-Step Plan:

1. Authentication: Log in as a Contributor user.
2. Capture Editor Context: Access the Elementor editor for a page to get the post_id and the wp_rest nonce.
3. Craft Payload: The payload should break out of an HTML attribute.
   • Target Field: Custom ID or Plus Extra Attributes -> Attribute Value.
   • Payload: x" onmouseover="alert(document.domain)" data-x="
4. Send Update Request: Use http_request to send a POST request to the Elementor REST API endpoint to update the post content.
   • URL: https://TARGET/wp-json/elementor/v1/data/<POST_ID>
   • Method: POST
   • Headers:
     • Content-Type: application/json
     • X-WP-Nonce: <EXTRACTED_NONCE>
   • Body: A JSON structure representing the Elementor widget tree, including the malicious payload in the widget's settings.

6. Test Data Setup

1. Plugin Version: Ensure "The Plus Addons for Elementor" v6.4.11 is installed.
2. User: Create a user with the contributor role.
3. Page: Create a page with the title "Research Page" and identify its ID.
4. Enable Features: Ensure "Plus Extra Attributes" is enabled in the plugin's settings (if testing that specific vector).

7. Expected Results

1. Response: The REST API should return a 200 OK indicating the post was saved.
2. Rendering: When visiting the page at https://TARGET/?p=<POST_ID>, the HTML source should contain the injected payload:

   <div id="x" onmouseover="alert(document.domain)" data-x="" ...>
   

3. Execution: Triggering the onmouseover event (or using a <script> tag if the field is echoed outside an attribute) will execute the JavaScript.

8. Verification Steps

1. WP-CLI Verification: Check the post metadata to see the stored payload:
   • wp post meta get <POST_ID> _elementor_data
2. Database Check: Inspect the wp_postmeta table directly if needed:
   • wp db query "SELECT meta_value FROM wp_postmeta WHERE post_id=<POST_ID> AND meta_key='_elementor_data'"
3. Frontend Inspection: Use http_request (GET) on the public page URL and grep for the payload string.

9. Alternative Approaches

• Shortcode Vector: If the Elementor Editor is restricted, attempt to use the plugin's shortcodes in a standard post. If a shortcode attribute like id or class is vulnerable:
  • Payload: [tp_button id='"><script>alert(1)</script>']
• Other Widgets: The "Plus Addons" package contains many widgets. If the "Heading" widget is patched, test the "Accordion", "Tabs", or "Info Box" widgets, as the same vulnerable code pattern often replicates across similar components in the same plugin.