CVE-2025-58046 is a critical (CVSS 9.8) remote code execution flaw in the Impala data source of DataEase. Insufficient filtering of JDBC connection strings allows JNDI injection and RMI deserialization. Versions up to and including 2.10.12 are affected. It is patched in 2.10.13, and the advisory says no workarounds exist.
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 advisory recommends upgrading to the latest version and states there are no known workarounds.
The affected code is the getJdbc method of the Impala data source class, as named in the advisory. The record says the flaw is reached by editing a data source and supplying a crafted JDBC connection string.
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
- Upgrade DataEase to 2.10.13 or later. No workaround is documented.
- Confirm the new version is running after restart.
- Restrict the DataEase web port to the networks and users that need it, and review who can create or edit data sources.
- Limit outbound connections from the DataEase host so it cannot reach arbitrary internal or external addresses.
- Review data source definitions and server logs from before the upgrade for connection strings you do not recognise.
- Limit outbound network access from the application server so it cannot reach arbitrary hosts.
- Restrict who may create or edit data sources, since that is the feature the weakness sits behind.
Why it matters
The Impala data source builds a JDBC URL from user supplied settings and did not filter enough of what it accepted. A crafted string can name a remote resource, and the driver then fetches and rebuilds objects from it. That is the same family of weakness as the DB2 flaw fixed earlier in the same product.
The record classifies the weakness as CWE-502 (Deserialization of Untrusted Data) and CWE-74 (Injection).
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
Who can reach the vulnerable function?
The record says it is reached by editing a data source with a crafted connection string, so anyone allowed to manage data sources is the relevant group. The CVSS vector lists no privileges required, so check your own access controls rather than assume.
Are there workarounds?
The advisory says no known workarounds exist. Upgrade to 2.10.13 or later.
Sources
Last reviewed: 18 October 2026.
