CVE-2025-58045 is a critical (CVSS 9.8) server-side request forgery in DataEase, the open source data analytics platform. An earlier DB2 fix blocked only the rmi parameter and missed ldap. Versions up to 2.10.12 are affected. The fix is in 2.10.13, and the advisory says to update to it or later.
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 2.10.13 or later and lists no workarounds other than upgrading.
The record notes that on newer Java versions ldap deserialization is disabled by default, so remote code execution is prevented there, but the SSRF remains exploitable.
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. The advisory documents no other workaround.
- Confirm the running version after the 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
This flaw exists because a patch was incomplete. The earlier fix for DB2 JDBC deserialization blocked the rmi parameter by name and left ldap alone. A block list has that weakness: it only stops what its author thought of. The ldap parameter let the server be told to make a request to an address chosen by someone else.
The record classifies the weakness as CWE-918 (Server-Side Request Forgery).
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
Does a newer Java version make this safe?
Only partly. The record says newer Java disables ldap deserialization by default, which prevents code execution, but the server side request forgery still works, so upgrade DataEase anyway.
Is there a workaround?
The advisory documents none besides upgrading to 2.10.13 or later.
Sources
Last reviewed: 18 October 2026.
