CVE-2025-57773 is a critical (CVSS 9.8) flaw in DataEase, the open source business intelligence tool. Unfiltered DB2 connection parameters allow JNDI injection that can lead to deserialization and file writes. It is fixed in 2.10.12, but later advisories fixed related bugs in 2.10.13, so plan for 2.10.13 or newer.
What's affected
DataEase versions before 2.10.12, per the record and the GitHub advisory. The fixed version is 2.10.12.
The record says exploitation needs commons-collections 4.x and aspectjweaver-1.9.22.jar on the classpath. Treat that as a condition worth confirming in your build, not as a reason to wait.
Three more DataEase flaws from the same period (CVE-2025-58045, CVE-2025-58046 and CVE-2025-58748) affect versions up to 2.10.12 and are fixed in 2.10.13. Moving only to 2.10.12 leaves those open.
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. That covers this fix and the related ones.
- Confirm the new version is running by checking the image tag or package version 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 root cause is that DB2 data source parameters were passed on without filtering. A connection string is not just a hostname. In Java it can carry parameters that tell the driver to look up a remote resource, and a JNDI lookup can pull an object from a place the attacker names. Rebuilding that object triggers deserialization, which the record says here ends in files being written.
The record classifies the weakness as CWE-502 (Deserialization of Untrusted Data) and CWE-94 (Code 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.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which DataEase version fixes CVE-2025-57773?
Version 2.10.12 fixes it, but related flaws were fixed in 2.10.13, so upgrade to 2.10.13 or later.
Is CVE-2025-57773 on the CISA KEV list?
No. The record shows it is not in the Known Exploited Vulnerabilities catalog, and no advisory we read reports exploitation in the wild.
Sources
Last reviewed: 18 October 2026.
