DataEase EUVD-2026-23291

Exploitation requires an authenticated DataEase account (CVSS PR:L) with the ability to create or register a datasource - specifically an API-type datasource whose getTables response can be controlled to return a malicious deTableName. That crafted table name is what bypasses the existing table-existence validation in DatasourceServer.java and reaches the unparameterized String.format query in CalciteProvider.java via /datasource/getTableField. Limiting factors: valid credentials plus datasource-creation privilege are mandatory, so anonymous/unauthenticated attackers cannot exploit it; SSVC rates it non-automatable because the multi-step registration-then-query flow resists trivial mass scanning. Only DataEase 2.10.20 and earlier are affected.

The signals are moderately conflicting and warrant nuance. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N, VC:H/VI:H, score 8.6) indicates a network-reachable, low-complexity attack with high confidentiality and integrity impact, and SSVC rates Technical Impact as 'total' with a proof-of-concept available. However, PR:L means valid authentication is required, SSVC marks Automatable as 'no' (the multi-step datasource-registration bypass resists mass scanning), and EPSS is only 0.03% (8th percentile) with no CISA KEV listing. Taken together this is a genuine, exploitable post-authentication data-exposure flaw that should be patched promptly in exposed multi-tenant deployments, but it is not a wormable internet-wide emergency: exploitation is targeted and gated by an account. Prioritize based on exposure and account trust model rather than raw CVSS alone.

An authenticated DataEase user with permission to add datasources registers a new API datasource whose returned table metadata includes a deTableName crafted with an embedded SQL payload. They then call /datasource/getTableField for that table; because getTables reports the malicious name as valid, DatasourceServer's check passes and CalciteProvider.java executes the injected SQL, letting the attacker perform error-based extraction of sensitive database contents. A proof-of-concept is indicated by the SSVC assessment, and the low attack complexity (AC:L) means no special timing or race conditions are needed.