DataEase EUVD-2026-44780

Requires an authenticated DataEase account with permission to reach /datasource/upload and to create datasources (CVSS PR:L - a low-privilege user, not an anonymous visitor). The concrete prerequisites are: uploading a payload.zip through the Excel/datasource upload endpoint, creating an H2-type datasource whose JDBC URL uses the zip: file protocol to reference the uploaded archive containing test.mv.db with precompiled Java aliases, and executing an SQL dataset so CalciteProvider.jdbcFetchResultField reaches statement.executeQuery(). Limiting factors: exploitation is gated on valid credentials with datasource-creation rights, the target must be an unpatched version below 2.10.23, and no end-user interaction is required (UI:N). Deployments that restrict datasource creation to administrators materially reduce the exposed population.

This is a genuine priority rather than a paper high-CVSS issue: the attack yields arbitrary Java code execution over the network at low complexity, limited only by the need for an authenticated low-privilege account (CVSS 4.0 AV:N/AC:L/AT:N/PR:L/UI:N). The key caveat is that the vendor CVSS 4.0 vector rates only VC:H (confidentiality high) with VI:N/VA:N, producing a 7.1 that understates the real impact - arbitrary code execution should also carry integrity and availability impact, so true severity is closer to an 8.8-class RCE. No EPSS score, POC, or KEV entry was supplied, so exploitation probability cannot be quantified from the input; treat that absence as unknown, not as low risk. Because a working fix and two commits are public, reverse-engineering an exploit from the diff is realistic, which raises practical urgency despite no confirmed in-the-wild activity.

A user with a low-privilege DataEase account uploads a crafted payload.zip through the Excel/datasource upload API, then defines an H2 datasource whose JDBC URL points into that archive via the zip: protocol so H2 loads a malicious test.mv.db containing precompiled Java aliases. When the attacker runs an SQL dataset against that datasource, CalciteProvider.jdbcFetchResultField calls statement.executeQuery(), triggering the aliases and executing arbitrary code on the server. No public exploit identified at time of analysis, but the fix commits make the attack path recoverable.