Safeguard
Vulnerability Analysis•

CVE-2025-58748: Critical RCE in DataEase H2 Data Source

DataEase up to 2.10.12 does not validate the H2 JDBC URL prefix, so a crafted configuration can lead to remote code execution. Upgrade to 2.10.13 or later.

Safeguard Security Team
3 min read

CVE-2025-58748 is a critical (CVSS 9.8) remote code execution flaw in the H2 data source of DataEase. The code never checks that a JDBC URL starts with jdbc:h2, so a crafted configuration can load a remote XML resource. Versions up to 2.10.12 are affected, and 2.10.13 fixes it.

What's affected

DataEase versions up to and including 2.10.12, per the record and the GitHub advisory.

Fixed in 2.10.13. The recommended remediation is 2.10.13 or later, and the advisory says no workarounds exist.

The affected file is H2.java, which handles the H2 data source.

How to check if you're exposed

DataEase usually runs as a container or a packaged server. Find the version you have deployed from the image tag or the install directory.

docker ps --format '{{.Names}} {{.Image}}' | grep -i dataease
docker images | grep -i dataease

If you installed it from a release package, check the version file or release folder name in the install directory. Anything at or below the version named above is in scope. Then ask a second question: which networks can reach the DataEase web port, and who holds an account that is allowed to create or edit data sources?

What to do now

  1. Upgrade DataEase to 2.10.13 or later.
  2. Confirm the new version is running after restart.
  3. Restrict the DataEase web port to the networks and users that need it, and review who can create or edit data sources.
  4. Limit outbound connections from the DataEase host so it cannot reach arbitrary internal or external addresses.
  5. Review data source definitions and server logs from before the upgrade for connection strings you do not recognise.
  6. Limit outbound network access from the application server so it cannot reach arbitrary hosts.
  7. Restrict who may create or edit data sources, since that is the feature the weakness sits behind.

Why it matters

The H2 data source accepted any JDBC URL without checking that it really was an H2 URL. That let a configuration substitute a different driver and pass parameters that cause the application to load a Spring application context from a remote XML file. Loading configuration from a remote location the attacker picks means running their definitions inside the server process.

The record classifies the weakness as CWE-502 (Deserialization of Untrusted Data).

Deserialization and connection string flaws share a pattern. The application accepts a value that describes where to connect or what object to rebuild, and it trusts that value too much. If the value can point at a remote service, the server may fetch and process content that someone else controls.

The defensive pattern is an allow list rather than a block list. Accepting only the connection parameters you expect is safer than trying to name every dangerous one, because a block list fails the moment a parameter nobody thought of is used.

The record shows this CVE is not in the CISA Known Exploited Vulnerabilities catalog.

Quick check

What is the simplest description of the cause?

The H2 data source did not verify that the URL it was given began with jdbc:h2, so another driver could be swapped in.

What is the fixed version?

DataEase 2.10.13. Versions up to 2.10.12 are affected.

Sources

Last reviewed: 18 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.