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` 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.
