CVE-2025-64164 is a critical (CVSS 9.8) flaw in DataEase, the open source data visualization tool. It did not properly filter Oracle JDBC connection settings, creating a risk of JNDI injection. Versions 2.10.14 and below are affected, and version 2.10.15 contains the fix, so plan an upgrade.
What's affected
The NVD record says DataEase 2.10.14 and below are affected and 2.10.15 is fixed. The record references the commit that fixed it, the v2.10.15 release and advisory GHSA-q754-4pc2-wjqw. We could not retrieve the advisory text, so use it to confirm the details.
A follow-up CVE, CVE-2025-64428, shows that the blacklist approach was still incomplete after the 2.10.14 patch. That one is fixed in 2.10.17. If you are upgrading anyway, choose 2.10.17 or later.
How to check if you're exposed
Check the version of your DataEase deployment:
docker ps --format '{{.Names}} {{.Image}}'
If it is 2.10.14 or below, you are in scope. Next, list the data sources configured in DataEase and note which ones are Oracle. The advisory concerns how DataEase builds JDBC connections to Oracle, so instances that never use that connector are in a different position, though the safest answer is still to upgrade.
Also check who can create or edit data sources. The CVSS vector in the record shows no privileges required, so this matters most for instances reachable from outside. Review the host for unexpected outbound connections.
What to do now
- Upgrade DataEase to 2.10.17 or later, which includes the 2.10.15 fix for this CVE and the later fix for CVE-2025-64428.
- Keep the instance off the public internet or behind an authenticating proxy.
- Restrict outbound traffic from the DataEase host to the data sources it needs.
- Audit the configured data sources and remove those you do not use.
- Rotate stored database credentials if you suspect abuse.
Why it matters
The record lists CWE-502, deserialization of untrusted data, as the weakness. JNDI is the Java Naming and Directory Interface. When an application lets outside input choose a JNDI or similar lookup target, it can be steered to load objects from somewhere it should not. The advisory language, "did not properly filter when establishing JDBC connections to Oracle", points at a connection string that could carry that input.
The maintainers' answer was to filter. Filters for this kind of input tend to need follow ups, which is what the later CVE shows. This CVE is not on the CISA Known Exploited Vulnerabilities list in the record.
Quick check
Do I have to use Oracle to be affected?
The advisory concerns Oracle JDBC connections. Even so, upgrade, because related issues were fixed in later releases.
What does JNDI injection mean here?
The record describes a risk where input used in a connection setting reaches a naming lookup without enough filtering.
Sources
Last reviewed: 18 October 2026.
