CVE-2024-13445

Executive Summary

CVE-2024-13445 is a Stored Cross-Site Scripting (XSS) vulnerability in the Elementor Website Builder plugin for WordPress, affecting all versions up to and including 3.27.4. The flaw resides in insufficient input sanitization and output escaping of the border, margin, and gap parameters within the page builder’s styling controls. Authenticated attackers with Contributor-level access or higher can inject arbitrary web scripts into pages. When a victim (including administrators or visitors) accesses the compromised page, the injected script executes in their browser, potentially leading to session hijacking, credential theft, or defacement.

This vulnerability is particularly dangerous in the WordPress ecosystem because Elementor is one of the most widely used page builders, with over 5 million active installations. The CVSS score of 6.4 (Medium) reflects the need for authentication, but the impact is amplified by the high prevalence of Contributor-level accounts in multi-author WordPress sites.

Supply Chain & Package Security

This is a WordPress plugin vulnerability, not an NPM, PyPI, Go, or Ruby package issue. However, the plugin may bundle third-party JavaScript libraries (e.g., React, jQuery) that could be leveraged in exploitation. No supply chain compromise has been identified in the plugin’s distribution channels.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely via HTTP.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): Low (L) – Requires Contributor-level authentication.
• User Interaction (UI): None (N) – No victim action needed beyond page access.
• Scope (S): Changed (C) – The vulnerable component (Elementor) impacts the broader WordPress environment.
• Confidentiality (C): Low (L) – Limited data exposure via script execution.
• Integrity (I): Low (L) – Script injection can modify page content.
• Availability (A): None (N) – No direct denial of service.

Threat Level: Medium. The requirement for authentication reduces the attack surface, but the widespread use of Elementor and the prevalence of Contributor accounts in WordPress make this a realistic threat for multi-author sites.

Deep Dive & Mechanics

The vulnerability exists in Elementor’s styling controls, specifically the border, margin, and gap parameters. These parameters are processed by the plugin’s PHP backend and then rendered in the frontend HTML. The plugin fails to properly sanitize user input and escape output when generating CSS or inline styles.

Attack Flow:

1. An attacker with Contributor-level access creates or edits a page using Elementor.
2. The attacker injects malicious JavaScript into the border, margin, or gap fields (e.g., via the custom CSS or style controls).
3. The plugin stores the unsanitized input in the WordPress database.
4. When any user (including administrators) views the page, the injected script executes in their browser.

Root Cause: The plugin uses esc_attr() or similar functions inconsistently, or fails to apply context-aware escaping for CSS values. For example, a border value like 1px solid red might be accepted, but an attacker can inject 1px solid red; background: url('javascript:alert(1)') or use event handlers in inline styles.

WordPress Context: This is a classic stored XSS in the WordPress ecosystem, where the plugin’s custom post types and shortcodes are the attack surface. The vulnerability is not related to Apache or Nginx configuration.

Vulnerable vs. Patched Code

Since no official patch is available, the following is a hypothetical comparison based on common XSS fixes.

Vulnerable Code (PHP):

// In Elementor's controls/classes/Control_Base.php
public function get_value( $control_value ) {
    // No sanitization or escaping
    return $control_value;
}

Patched Code (Hypothetical):

// Patched version would use wp_kses_post() or esc_js() for CSS values
public function get_value( $control_value ) {
    // Sanitize CSS values
    $sanitized = sanitize_text_field( $control_value );
    // Escape for output
    return esc_attr( $sanitized );
}

Key Difference: The patched version applies sanitize_text_field() to strip malicious content and esc_attr() to escape output, preventing script injection.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• WordPress site with Elementor <= 3.27.4 installed.
• Contributor-level account credentials.

Exploit Steps:

1. Log in as a Contributor.
2. Create a new page or edit an existing one with Elementor.
3. Add a widget (e.g., Heading, Text, or Image).
4. In the widget’s Advanced tab, locate the border, margin, or gap fields.
5. Inject the following payload into the border field:

   1px solid red; background: url('javascript:alert(document.cookie)')
   

6. Save and publish the page.
7. When an administrator or visitor accesses the page, the JavaScript executes.

Alternative Payload (using event handler):

1px solid red; onmouseover="alert(1)"

Note: No public exploit code is available, but the above demonstrates the attack vector.

Blue Team (Detection & Response)

Detection:

• Monitor for unusual CSS values in Elementor’s custom fields.
• Look for javascript: URIs or event handlers in page content.
• Use WAF rules to block inline script patterns.

Response:

• Immediately revoke Contributor-level accounts if suspicious activity is detected.
• Review all pages edited by low-privilege users for injected scripts.
• Apply virtual patching via WAF until an official patch is released.

Indicators of Compromise (IOCs)

• File Hashes: N/A (no malicious files identified).
• Network Indicators: HTTP requests to /wp-admin/post.php with action=edit and post_type=elementor from Contributor accounts.
• Database Indicators: Rows in wp_postmeta with meta_key containing _elementor_data and meta_value containing javascript: or on*= patterns.
• Log Indicators: WordPress debug logs showing wp_kses failures or esc_attr bypass attempts.

Detection Engineering

YARA Rule

rule CVE_2024_13445_Elementor_XSS {
    meta:
        description = "Detects malicious CSS values in Elementor post meta"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-13445"
    strings:
        $css_inject = /(border|margin|gap)\s*:\s*[^;]*javascript:/i
        $event_handler = /(on\w+)\s*=\s*["']?[^"']*["']?/i
    condition:
        any of them
}

Sigma Rule

title: CVE-2024-13445 Elementor Stored XSS Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential XSS payloads in Elementor page builder fields
author: Valters IT
logsource:
    category: webserver
    product: wordpress
detection:
    selection:
        http.url|contains: "/wp-admin/post.php"
        http.method: "POST"
        http.body|contains:
            - "border"
            - "margin"
            - "gap"
        http.body|re: "(javascript:|on\w+=)"
    condition: selection
falsepositives:
    - Legitimate CSS values with "javascript:" in comments (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-13445 Elementor Stored XSS Attempt"; flow:to_server,established; content:"/wp-admin/post.php"; http_uri; content:"border|margin|gap"; http_client_body; pcre:"/(javascript:|on\w+=)/i"; classtype:web-application-attack; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable Elementor on production sites until a patch is released.
2. Restrict Contributor-level accounts to only trusted users.
3. Apply WAF rules to block javascript: and event handler patterns in POST requests.

Long-Term Fix:

• Monitor Elementor’s official channels for a patched version (expected > 3.27.4).
• Update to the latest version as soon as it is available.
• Implement input validation and output escaping for all custom fields.

Workaround:

• Use a security plugin (e.g., Wordfence) to block XSS payloads.
• Manually audit all pages created by low-privilege users.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert