CVE-2025-57772 is a critical (CVSS 9.8) code injection flaw in DataEase, the open source business intelligence tool, in all versions before 2.10.12. A data source check can be steered into using the H2 JDBC driver, which skips the filtering meant to block it. Upgrade to 2.10.12 or later.
What's affected
DataEase is an open source business intelligence and data visualization tool. The NVD record says the problem exists in versions prior to 2.10.12. The project's GitHub security advisory lists the affected range as 2.10.11 and below, and names 2.10.12 as the patched release.
The record carries a CVSS 3.x score of 9.8, which is the top of the critical band. The weakness is tagged CWE-94, improper control of generation of code, usually called code injection. The record was published on 25 August 2025.
This is not listed in the CISA Known Exploited Vulnerabilities catalogue, and neither the record nor the advisory we read claims exploitation in the wild. The advisory does include a demonstration written by the reporter. We do not repeat it here.
One detail changes how you should read the number. The advisory describes this as a bypass of an earlier fix. DataEase had already added filtering around H2 connection strings to block dangerous options. This issue shows a second path that never reaches that filter. If you patched the earlier H2 problem and stopped there, you are still exposed until you reach 2.10.12.
How to check if you're exposed
Find every DataEase instance you run, including test and demo servers that were stood up for a single project. The version is visible in the product's own interface. If you deploy with containers, the image tag usually tells you too:
docker ps
Look for a DataEase image and read its tag. Anything at 2.10.11 or lower is in the affected range. If your tag says latest or has no number, check the version in the application itself before assuming you are current.
Next, ask who can reach the application. DataEase is a web tool meant for analysts and business users, and many teams put it on an internal network with wide access. The question to answer is who can log in and who can reach the page that tests data source connections. Anyone with that access matters, because the flaw sits in how data source settings are validated.
Finally, check what the service can do. A BI server usually holds credentials for the databases it queries and often runs with network access to all of them. If the process were taken over, that access is what an attacker would inherit.
What to do now
- Upgrade DataEase to 2.10.12 or later. The advisory names this as the fix and lists no other workaround.
- If you cannot upgrade today, restrict access to the application to a small set of trusted addresses, and limit who holds an account that can create or test data sources.
- Review the data sources already defined in your instance. Look for any that use the H2 driver or a connection string you do not recognise, and remove anything nobody can explain.
- Check the host and the application logs for unexpected outbound connections from the DataEase process and for data source tests you did not run.
- Rotate credentials stored in DataEase for connected databases if you see any sign of misuse, and run the service under a least privilege account with narrow network egress.
- Add DataEase to your dependency and product inventory so the next advisory reaches someone who owns it.
Why it matters
DataEase accepts a JDBC connection description when someone adds a data source. JDBC is the standard Java interface for talking to databases, and a connection string can carry settings that change what the driver does. The H2 database driver is one where certain options can lead to code running on the server. That is why an earlier fix filtered those options.
According to the advisory, the code that chooses how to validate a connection looks at the declared data source type. When the type was changed to a different database kind, the logic took a branch whose check returned the supplied connection string directly. That path never applied the H2 filter. The request could still name the H2 driver, so the dangerous driver was used after all. The lesson is the usual one for filtering approaches: a blocklist applied in one branch does not protect the others.
The class matters beyond DataEase. Any application that lets users supply a connection string, a URL or a driver name is handing out configuration that can execute behaviour. The safer design allows only known data source types, builds the connection string on the server from separate fields and rejects unknown drivers outright.
For a security team the practical risk is the position of a BI server. It sits close to production data, holds many credentials and is often forgotten in patch cycles. A critical flaw there deserves the same urgency as one in a gateway.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Which DataEase versions are fixed?
The advisory says 2.10.12 is the patched version and that 2.10.11 and earlier are affected. Upgrade to 2.10.12 or later.
Is there a workaround if I cannot upgrade?
The advisory lists upgrading as the only recommendation. Restricting who can reach the application and who can create data sources reduces exposure in the meantime, but it is not a fix.
Was this exploited in the wild?
The record does not flag it as a CISA Known Exploited Vulnerability, and the advisory does not say it has been exploited. Treat that as the state of the public record, not as a guarantee.
Sources
Check the libraries your own projects pull in with the free in-browser scan at gold.safeguard.sh/scan.
Last reviewed: 18 October 2026.
