DataEase CVE-2026-104143

Requires an authenticated DataEase account with permission to create or edit dataset fields and set a 'custom' dateFormatType on a date field (deType=1, deExtractType=0); the crafted DatasetTableFieldDTO.dateFormat is inserted unvalidated into the date-conversion templates used by Dimension2SQLObj, CustomWhere2Str, Field2SQLObj, WhereTree2Str, and ExtWhere2Str. Exploitation is triggered only when a chart actually renders that field. Reliable exploitation requires the field to sit on a cross-datasource dataset, where Calcite parsing is bypassed; on a single-datasource dataset the attacker additionally must craft the payload to survive Calcite reserialization as a valid string literal, which significantly limits that path. Primary limiting factors: valid authentication with dataset-edit rights (PR:L), the need for a chart render, and the cross-datasource requirement for the easy path. Affected versions are all prior to 2.10.26.

This is a credible, above-average priority for any organization running DataEase, but it is not an unauthenticated internet-wide emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H, score 8.7) shows a network-reachable, low-complexity flaw with full compromise of the backend database, but crucially gated behind PR:L - an attacker must already hold a valid authenticated DataEase account with dataset-editing rights. No EPSS score was provided in the input, and there is no CISA KEV listing and no public exploit identified at time of analysis, so this is 'no public exploit identified at time of analysis' rather than active exploitation. The vendor security advisory (GHSA-h32f-m89w-g35f) and the patch commit are the only intelligence sources; they confirm the mechanism (an unvalidated dateFormat concatenated into SQL-building templates) but provide no exploitation telemetry. One notable conflict: the single input Tag 'Authentication Bypass' and CWE-289 mischaracterize the bug - the description and patch show a stored SQL injection performed by an already-authenticated user, not a bypass of authentication. A second nuance to verify: reliable exploitation is described only for cross-datasource datasets; single-datasource datasets additionally require the payload to survive Calcite reserialization as a valid string literal, which raises real-world attack complexity on that path. Net: treat as a high-value internal/post-authentication threat (malicious or compromised low-privilege users), patch promptly, but it does not carry the drive-by risk of a PR:N flaw.

A low-privilege but authenticated DataEase user (or an attacker who has phished/compromised such an account) edits a date-type dataset field and sets a crafted 'custom' dateFormat value. When any chart renders that field on a cross-datasource dataset, Calcite parsing is bypassed and the attacker-controlled format string is concatenated directly into the generated SQL, letting the attacker read, modify, or destroy data in the backend database. No public exploit code is identified, but the fix commit publicly reveals the exact unvalidated code path, lowering the bar for exploit development.