CVE-2025-53006: Critical Bypass in DataEase PostgreSQL and Redshift

CVE-2025-53006 is a critical flaw (CVSS 9.8) in DataEase, the open source business intelligence tool. Its PostgreSQL and Redshift data source checks missed several JDBC parameters, including sslfactory, sslhostnameverifier and authenticationPluginClassName. Version 2.10.11 fixes it, so upgrade and limit who can edit data sources.

What's affected

The GitHub advisory GHSA-q726-5pr9-x7gm lists the Maven package io.dataease, affected versions 2.10.10 and earlier, and patched version 2.10.11. The NVD record says the same: versions before 2.10.11 are affected and the issue is patched in 2.10.11.

This CVE covers both PostgreSQL and Redshift. The advisory names the code in Redshift.java and Pg.java and says the blocklist is incomplete: besides socketfactory and socketfactoryarg, the parameters sslfactory, sslfactoryarg, sslhostnameverifier, sslpasswordcallback and authenticationPluginClassName behave similarly and need to be handled.

The weakness is listed as CWE-153. The record scores it at 9.8 with a network attack vector, which reflects that the vulnerable setting can be reached through the application without special conditions.

How to check if you're exposed

Check which DataEase version you run. The version appears in the product after login, and a Docker or Compose deployment shows the image tag:

docker images | grep -i dataease

Any version up to and including 2.10.10 is in the affected range. Then review which accounts can create or edit data sources, because the weakness is reached through the connection settings of a data source. If many people can add data sources, the exposure is larger.

Also check what the DataEase server can reach on the network and which credentials it holds. A BI server usually has connections to production databases.

What to do now

1. Upgrade DataEase to 2.10.11 or later, after a backup of its metadata database.
2. Restrict who can create or edit data sources to the people who need it.
3. Place the DataEase server in a network segment that cannot reach the internet or sensitive hosts it does not need.
4. Review existing data source definitions for connection strings that contain unusual parameters you did not add.
5. Rotate the database credentials stored in DataEase if you find signs of misuse.

Why it matters

DataEase lets users connect to external databases by entering a host and connection options. JDBC drivers accept many options in a connection string, and some of them name a Java class to load or a file to fetch. If an application tries to protect itself with a list of banned parameter names, any option missing from the list becomes a way around the protection.

The advisories describe this exact pattern. An earlier fix blocked some parameters, and later reports showed that other parameters with similar behaviour were not covered. That is the usual limit of blocklists, and it is why an allow list of permitted options is the safer design. The record gives no sign of use in attacks, and the CVE is not on the CISA Known Exploited Vulnerabilities list. A BI server that holds database credentials deserves prompt patching.

Quick check

Sources

• GitHub advisory GHSA-q726-5pr9-x7gm
• Safeguard Gold entry

Last reviewed: 18 October 2026.