CVE-2026-123992

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 2.10.14 and below, the vendor added a blacklist to filter ldap:// and ldaps://, but omission of protection for the dns:// protocol results in an SSRF vulnerability. The issue 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.

A vulnerability was detected in DataEase up to 2.10.27. Affected by this vulnerability is the function WhitelistUtils.endsWithAny of the file WhitelistUtils.java of the component Authentication Filter. Performing a manipulation of the argument File results in unrestricted upload. It is possible to initiate the attack remotely. The exploit is now public and may be used.

A security vulnerability has been detected in DataEase up to 2.10.27/3.1.0. Affected is the function ExtWhere2Str.extWhere2sqlOjb of the file engine/trans/ExtWhere2Str.java of the component Chart Data Handler. Such manipulation of the argument operator leads to sql injection. The attack may be performed from remote. The exploit has been disclosed publicly and may be used.