DataEase EUVD-2026-44782

Requires an authenticated DataEase account with permission to create or edit SQL-type datasets, and the ability to set a SQL variable's defaultValue field (the exact attacker-controlled sink: ${var} entries processed by SqlparserUtils.handleVariableDefaultValue()). Triggering execution additionally requires a second condition - some user with dataset read permission must subsequently access the affected dataset, since it is stored/second-order rather than immediate. Limiting factors: exploitation is not possible for fully anonymous users (CVSS PR:L confirms authentication is required), it depends on the deployment granting dataset-authoring rights to the attacker, and it only affects DataEase instances running versions prior to 2.10.23. No non-default configuration is otherwise needed - SQL dataset variables are standard product functionality.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:H/VI:H/VA:L, no scope change) describes a network-reachable, low-complexity attack requiring only low privileges - an authenticated user able to author or edit SQL datasets - and no user interaction, yielding a High 8.7 score. The stored nature increases realistic impact: the payload fires when a second, potentially higher-value user with read permission opens the dataset, so it doubles as a persistence/pivot primitive rather than a one-shot injection. There is no CISA KEV listing and no EPSS score in the provided data, and no public exploit code was supplied, so this is not confirmed as actively exploited; the signal set points to a genuine but not yet weaponized High-priority issue rather than a low-real-risk high-CVSS artifact. The main limiting factor is the PR:L requirement - an anonymous internet attacker cannot trigger it without first obtaining an account with dataset-authoring rights, which lowers exposure for well-segmented deployments. EPSS and KEV data are absent from the input and should be checked before final prioritization.

A low-privileged DataEase user who can author SQL datasets creates one containing a variable whose defaultValue embeds a malicious SQL fragment (e.g. a subquery or UNION). When a colleague or administrator with read permission later opens that dataset, the backend concatenates the unescaped defaultValue into the executed query, running the attacker's SQL against the database with the application's DB credentials. No public exploit code was identified, but the low attack complexity and public fix commit make crafting one straightforward.