CVE-2025-64164: Dataease JNDI Injection Vulnerability

CVE-2025-64164 Overview

DataEase, an open source data visualization and analysis tool, contains a JNDI injection vulnerability in versions 2.10.14 and below. The application fails to properly filter user-supplied input when establishing JDBC connections to Oracle databases, allowing attackers to inject malicious JNDI references. Successful exploitation could enable remote code execution on vulnerable systems through deserialization attacks.

Critical Impact

Unauthenticated attackers can exploit improper input validation in Oracle JDBC connection handling to achieve remote code execution via JNDI injection, potentially leading to complete system compromise.

Affected Products

• DataEase versions 2.10.14 and below
• DataEase deployments with Oracle database connectivity configured
• All installations using the vulnerable Oracle JDBC driver integration

Discovery Timeline

• 2025-11-06 - CVE-2025-64164 published to NVD
• 2025-11-07 - Last updated in NVD database

Technical Details for CVE-2025-64164

Vulnerability Analysis

This vulnerability stems from CWE-502 (Deserialization of Untrusted Data) and manifests specifically in the Oracle JDBC connection handling code within DataEase. The application's Oracle.java class maintains a list of illegal parameters intended to block dangerous JNDI-related values, but the filtering implementation was insufficient to prevent all attack vectors.

JNDI injection attacks exploit Java's naming and directory interface to force the vulnerable application to load and execute attacker-controlled code. When a malicious JDBC URL containing JNDI references (such as ldap://, rmi://, or related protocols) bypasses input validation, the Oracle JDBC driver can be coerced into retrieving and deserializing malicious objects from an attacker-controlled server.

The network-accessible nature of this vulnerability, combined with no authentication requirements and low attack complexity, makes it particularly dangerous in exposed DataEase deployments.

Root Cause

The root cause lies in the insufficient input validation within the Oracle.java class responsible for handling JDBC connections. The original implementation used a static list (getIllegalParameters) to filter dangerous parameters including JNDI-related strings like java.naming.factory.initial, java.naming.provider.url, LDAP protocols, and other hazardous JDBC parameters. However, the filtering mechanism could be bypassed, allowing attackers to inject malicious JNDI references through the Oracle JDBC URL.

Attack Vector

The attack leverages the network-exposed DataEase application to inject JNDI references via Oracle JDBC connection parameters. An attacker can craft a malicious JDBC URL containing protocols such as ldap://, ldaps://, rmi://, or other JNDI-related parameters that bypass the existing blocklist. When processed by the vulnerable Oracle driver configuration, the application attempts to resolve the JNDI reference, connecting to an attacker-controlled server that delivers a malicious serialized Java object for execution.

public class Oracle extends DatasourceConfiguration {
    private String driver = "oracle.jdbc.driver.OracleDriver";
    private String extraParams = "";
-    private List<String> getIllegalParameters = Arrays.asList(
-            // 原有参数（如RMI相关）
-            "java.naming.factory.initial", "java.naming.provider.url", "rmi",
-            // 新增：LDAP协议及相关危险参数
-            "ldap://", "ldaps://", "java.naming.factory.object", "java.naming.factory.state",
-            // 其他JDBC危险参数
-            "autoDeserialize", "connectionProperties", "initSQL", "dns", "file", "ftp"
-    );
+    private List<String> getOracleIllegalParameters() {
+        return Arrays.asList(
+                // 原有参数（如RMI相关）
+                "java.naming.factory.initial", "java.naming.provider.url", "rmi",
+                // 新增：LDAP协议及相关危险参数
+                "ldap://", "ldaps://", "java.naming.factory.object", "java.naming.factory.state",
+                // 其他JDBC危险参数
+                "autoDeserialize", "connectionProperties", "initSQL", "dns", "file", "ftp"
+        );
+    }


    public String getJdbc() {
        if(StringUtils.isNoneEmpty(getUrlType()) && !getUrlType().equalsIgnoreCase("hostName")){
            if (!getJdbcUrl().startsWith("jdbc:oracle")) {
                DEException.throwException("Illegal jdbcUrl: " + getJdbcUrl());
            }
-            for (String illegalParameter : getIllegalParameters()) {
+            for (String illegalParameter : getOracleIllegalParameters()) {

Source: GitHub Commit 7b68eb3

Detection Methods for CVE-2025-64164

Indicators of Compromise

• Outbound connections from DataEase servers to unexpected LDAP or RMI services on non-standard ports
• JDBC connection attempts containing encoded or obfuscated JNDI lookup strings
• Unusual Java class loading or process spawning from the DataEase application context
• Network traffic to external servers containing serialized Java objects

Detection Strategies

• Monitor Oracle JDBC connection strings for JNDI-related patterns including ldap://, ldaps://, rmi://, and java.naming.* parameters
• Implement web application firewall rules to detect and block JNDI injection payloads in HTTP requests to DataEase endpoints
• Deploy network intrusion detection signatures for JNDI exploitation attempts targeting Java applications
• Analyze DataEase application logs for rejected JDBC URLs containing blocked parameters

Monitoring Recommendations

• Enable verbose logging for DataEase JDBC connection handling to capture all connection parameter attempts
• Configure egress filtering to alert on outbound LDAP (389/636) and RMI (1099) connections from application servers
• Implement runtime application self-protection (RASP) to detect deserialization attacks
• Set up alerts for Java process anomalies such as unexpected child processes or network connections

How to Mitigate CVE-2025-64164

Immediate Actions Required

• Upgrade DataEase to version 2.10.15 or later immediately
• Audit existing Oracle JDBC connection configurations for any suspicious or unexpected parameters
• Restrict network egress from DataEase servers to prevent outbound JNDI lookups to attacker-controlled infrastructure
• Review application logs for evidence of exploitation attempts

Patch Information

DataEase has released version 2.10.15 which addresses this vulnerability. The fix refactors the parameter filtering mechanism from a static list to a method-based approach (getOracleIllegalParameters()) and ensures proper validation of JDBC URLs. The patch is available via the GitHub Release v2.10.15. For technical details on the specific code changes, refer to the security commit 7b68eb3.

Workarounds

• If immediate patching is not possible, disable Oracle database connectivity in DataEase until the update can be applied
• Implement network-level blocking of outbound LDAP and RMI traffic from DataEase application servers
• Deploy a web application firewall with rules to detect and block JNDI injection patterns in request parameters
• Place DataEase behind an authenticated reverse proxy to reduce the attack surface

# Example iptables rules to block outbound JNDI-related protocols
iptables -A OUTPUT -p tcp --dport 389 -m owner --uid-owner dataease -j DROP
iptables -A OUTPUT -p tcp --dport 636 -m owner --uid-owner dataease -j DROP
iptables -A OUTPUT -p tcp --dport 1099 -m owner --uid-owner dataease -j DROP