From Auth Bypass to RCE: A 4-Vulnerability Exploit Chain in DataEase

The chain is greater than the sum of its vulnerabilities: chaining CVE-2026-40899, CVE-2026-40900, and CVE-2026-40901 leads to a critical outcome

TL;DR

The OX Research team identified a chain of 3 vulnerabilities in DataEase that, when combined with the authentication bypass we disclosed at the RSAC Conference in March, allows unauthenticated remote command execution on DataEase instances.

The vulnerabilities include a JDBC blocklist bypass, stacked SQL injection, Quartz poisoning, and Java deserialization. When chained together, they enable remote command execution and access to sensitive data stored in DataEase, which often contains highly sensitive business information as a BI application.

Users should upgrade to DataEase v2.10.21 or later as soon as possible.

Overview

We previously disclosed CVE-2026-23958 – an authentication bypass in DataEase – at the RSAC Conference 2026 in San Francisco. After the conference, we continued our research to determine whether the issue could be escalated to full remote code execution.

This effort led to the discovery of a three-vulnerability chain that, when combined with the original authentication bypass, enables complete compromise of DataEase instances.

We responsibly disclosed the full chain to DataEase, who patched it 10 days after our disclosure.

The vulnerabilities were assigned the following CVEs:

• CVE-2026-40899 – CVSS 6.5 (Medium)

• CVE-2026-40900 – CVSS 8.8 (High)

• CVE-2026-40901 – CVSS 8.8 (High)

The full attack flow is illustrated in the diagram below.

What is DataEase and Why We Researched It

DataEase is an open-source business intelligence (BI) and data visualization platform maintained by FIT2CLOUD. It offers a lightweight alternative to proprietary BI tools, enabling users to build interactive dashboards and connect to databases like MySQL, Oracle, and ClickHouse.

The project is widely adopted, with over 23K stars and 3.8K forks on GitHub, highlighting its popularity across organizations handling sensitive data. This made it a compelling target for research – especially following our previous authentication bypass finding – as issues in such platforms can have significant impact.

What We Discovered (CVE-2026-40899, CVE-2026-40900, CVE-2026-40901)

By reverse-engineering DataEase’s closed-source binaries, we uncovered three additional vulnerabilities that chain together — from arbitrary file read through SQL injection to Java deserialization — turning authenticated access into full remote code execution as root inside the application container.

The vulnerabilities were assigned CVE-2026-40899 (CVSS 6.5), CVE-2026-40900 (CVSS 8.8), and CVE-2026-40901 (CVSS 8.8).

Impact

• Remote Code Execution: Arbitrary command execution on the DataEase instance, enabling full system access and backend compromise

• Data exposure: Access to all connected databases, credentials, and sensitive business data

Who is Affected

All organizations running publicly accessible DataEase servers on vulnerable versions (up to v2.10.21) are affected.

Responsible Disclosure

We contacted the DataEase team on April 6, 2026, and the issue was resolved on April 16, 2026.

Recommendations

• Upgrade once possible to DataEase v2.10.21 or later

Technical Analysis – Three Vulnerability Chain

Vulnerability 1: Arbitrary File Read via JDBC Blocklist Bypass (CVE-2026-40899)

Our chain starts with Arbitrary File Read.

DataEase allows users to configure datasource connections through its API, and defines a JDBC parameter blocklist to reject dangerous parameters like allowLoadLocalInfile.

The blocklist is implemented in the Mysql class – which we found by reverse-engineering the closed-source binaries – and checks the constructed JDBC URL against 8 dangerous parameter names before passing it to the driver:

Looks reasonable.

But the class is annotated with Lombok’s @Data, which silently auto-generates setters for all fields – including illegalParameters.

This setter is invisible in the source code. It doesn’t appear in any .java file. But it is present in the compiled bytecode, and critically, it’s visible to Jackson.

When the API receives a datasource configuration as JSON, Jackson discovers setIllegalParameters() via reflection and calls it with whatever the attacker provides.

By sending ”illegalParameters”: [] in the request body, the attacker replaces the 8-item blocklist with an empty list before the validation runs. The check iterates zero times. All JDBC parameters pass through unchecked.

Exploitation

With the blocklist emptied, the attacker injects [allowLoadLocalInfile=true](https://dev.mysql.com/doc/connector-j/en/connector-j-connp-props-security.html) into the JDBC URL and points the datasource at a rogue MySQL server they control:

The MySQL protocol has a feature called LOAD DATA LOCAL INFILE where the server can request the client to send the contents of a local file.

Normally used for bulk data import, a rogue server abuses it: when DataEase’s backend connects and sends an init query, the rogue server replies with a LOCAL INFILE packet requesting /proc/1/environ. The JDBC driver – because allowLoadLocalInfile=true – reads the file and sends it back. The rogue server captures:

The internal MySQL credentials are now in the attacker’s hands. The security control was never circumvented – it was removed before it could run.

Vulnerability 2: SQL Injection via Stacked Queries (CVE-2026-40900)

With the internal MySQL credentials in hand, we needed a way to turn database access into something more dangerous.

DataEase exposes a previewSql endpoint that lets users run SQL queries against configured datasources.

By reverse-engineering the closed-source binaries, we found that the user-supplied SQL is simply wrapped in a subquery – with no validation that the input is a single SELECT:

Breaking Out

This wrapper seems harmless – until combined with Vulnerability 1.

The blocklist bypass also lets us inject allowMultiQueries=true, which tells the MySQL driver to accept multiple semicolon-separated statements.

The attacker breaks out:

The ) terminates the subquery early. The ; starts the attacker’s arbitrary SQL. The # comments out the rest. MySQL executes all three statements in sequence.

Exploitation

The attacker creates a datasource to the internal MySQL – using the credentials from Vulnerability 1 and the blocklist bypass to enable allowMultiQueries=true.

With stacked query injection as root, the attacker has full read/write access to every table in the application database.

The most dangerous target is qrtz_job_details – the Quartz scheduler’s job storage. This table contains serialized Java objects in its JOB_DATA column, and Quartz deserializes them automatically on a cron schedule. Overwriting this column with a malicious payload is the bridge to Vulnerability 3.

Vulnerability 3: Quartz Deserialization → Root RCE (CVE-2026-40901)

With arbitrary SQL execution against the application database, we needed a deserialization sink – and DataEase ships one out of the box.

The Gadget Chain

DataEase bundles three libraries that together form a classic Java deserialization attack surface:

• Quartz 2.3.2 – stores job definitions in the qrtz_job_details table, with a JOB_DATA BLOB column containing serialized Java objects. When Quartz fires a scheduled job, it deserializes this BLOB with a raw ObjectInputStream – no deserialization filter, no class allowlist.

• Commons Collections 3.2.1 – provides the InvokerTransformer gadget chain, which triggers Runtime.exec() during deserialization.

• Velocity 1.7 – a legacy dependency that pulls Commons Collections 3.2.1 onto the classpath. The application already ships the newer velocity-engine-core-2.3.jar, making the legacy JAR redundant.

Exploitation

Using the SQL injection from Vulnerability 2, the attacker overwrites the JOB_DATA column of the Datasource/check_status Quartz job with a CC6 payload containing a reverse shell command:

This job fires on a cron schedule every 6 minutes. When it does, Quartz deserializes the injected blob, the gadget chain fires, and Runtime.exec() runs the attacker’s command leading to Remote Command Execution. The JVM runs as root inside the container.

Full Exploitation – PoC

Summary

We discovered three vulnerabilities in DataEase that chain together to achieve root remote code execution.

The chain required reverse engineering DataEase’s closed-source binaries to understand how the internal components interact.

First, a Lombok @Data annotation allows an attacker to empty the JDBC parameter blocklist via the API, enabling arbitrary file read through a rogue MySQL server – leaking internal database credentials (CVE-2026-40899).

Second, the previewSql endpoint wraps user SQL in a subquery without validation, combined with the now-injectable allowMultiQueries parameter, the attacker breaks out with stacked queries to write arbitrary data into the application database (CVE-2026-40900).

Third, the attacker poisons a Quartz scheduler job with a Commons Collections deserialization payload, which executes as root when the cron trigger fires – delivering a full reverse shell (CVE-2026-40901).

Combined with CVE-2026-23958, the entire chain is exploitable without any credentials.

The post From Auth Bypass to RCE: A 4-Vulnerability Exploit Chain in DataEase appeared first on OX Security.