CVE-2025-64163

In DataEase before version 2.10.23, a vulnerability exists in enterprise token handling. The TokenFilter#doFilter() passes X-DE-TOKEN values to TokenUtils.validate(), which only checks token presence and length, then userBOByToken() uses JWT.decode() without signature verification. This allows forged tokens with arbitrary uid and oid values to be accepted when licenseValid=true.

In DataEase prior to version 2.10.23, a vulnerability allows remote code execution (RCE) via Redshift datasource connections. An attacker can load a malicious rsjdbc.ini configuration file from the temporary directory, leading to code execution through reflection during a normal JDBC connection.

Dataease, an open source data visualization tool, versions prior to 2.10.17 are vulnerable to JNDI injection. A blacklist was added in 2.10.14, but JNDI injection remains possible via iiop, corbaname, and iiopname schemes. The vulnerability has been fixed in version 2.10.17.

DataEase versions 2.10.14 and below did not properly filter when establishing JDBC connections to Oracle, creating a risk of JNDI injection. This is fixed in version 2.10.15.

In DataEase versions up to 2.10.12, the H2 data source implementation (H2.java) does not verify that a provided JDBC URL starts with jdbc:h2. This lack of validation allows a crafted JDBC configuration that substitutes the Amazon Redshift driver and leverages socketFactory and socketFactoryArg parameters to invoke org.springframework.context.support.FileSystemXmlApplicationContext or ClassPathXmlApplicationContext with an attacker-controlled remote XML resource, resulting in remote code execution. The issue is fixed in version 2.10.13.

In DataEase versions up to and including 2.10.12, the Impala data source is vulnerable to remote code execution due to insufficient filtering in the getJdbc method of the io.dataease.datasource.type.Impala class. Attackers can construct malicious JDBC connection strings that exploit JNDI injection and trigger RMI deserialization, enabling remote command execution by editing the data source and providing a crafted JDBC string referencing a remote configuration file. The issue is patched in version 2.10.13.

In DataEase versions up to 2.10.12, the patch introduced to mitigate DB2 JDBC deserialization remote code execution attacks only blacklisted the rmi parameter. The ldap parameter in the DB2 JDBC connection string was not filtered, allowing attackers to exploit the DB2 JDBC connection string to trigger server-side request forgery (SSRF). In higher versions of Java, ldap deserialization (autoDeserialize) is disabled by default, preventing remote code execution, but SSRF remains exploitable. The issue is fixed in version 2.10.13.

DataEase is an open source data visualization and analysis tool. Prior to 2.10.26, authenticated users can store a crafted custom dateFormat for a dataset field. DatasetTableFieldDTO.dateFormat is inserted without validation into date conversion templates used by Dimension2SQLObj, CustomWhere2Str, Field2SQLObj, WhereTree2Str, and ExtWhere2Str. When a chart renders the field on a cross-datasource dataset, Calcite parsing is bypassed and the crafted format can directly alter the generated SQL.

DataEase is an open source data visualization and analysis tool. Prior to 2.10.26, authenticated users can store crafted FieldGroupDTO.min, FieldGroupDTO.max, FieldGroupDTO.startTime, or FieldGroupDTO.endTime values in dataset group-field binning definitions. Utils.transGroupFieldToSql inserts these free-form values into generated CASE expressions without validation, and the resulting SQL can reach unparameterized backend query execution when a chart uses the field.

DataEase is an open source data visualization and analysis tool. Authenticated users with datasource access can supply crafted schema names, connection usernames, table names, or database names to datasource metadata operations, including getSchema, validate, save, and update flows. CalciteProvider inserts these identifiers into metadata queries that are executed through a plain JDBC Statement, allowing the generated SQL to be altered and run against the configured backend with application-held datasource credentials.