CVE-2026-104142 in DataEase
Summary
by MITRE • 10/14/2026
DataEase is an open source data visualization and analysis tool. Prior to 2.10.26, authenticated users can store crafted FieldGroupDTO.min, FieldGroupDTO.max, FieldGroupDTO.startTime, or FieldGroupDTO.endTime values in dataset group-field binning definitions. Utils.transGroupFieldToSql inserts these free-form values into generated CASE expressions without validation, and the resulting SQL can reach unparameterized backend query execution when a chart uses the field. This stored SQL injection can compromise the confidentiality, integrity, and availability of the configured backend database. This issue is fixed in version 2.10.26.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
DataEase serves as an open-source platform designed for data visualization and advanced analysis, enabling users to create comprehensive dashboards from various data sources. A critical security vulnerability was identified within versions prior to 2.10.26 that affects the integrity of database interactions when utilizing specific dataset group-field binning configurations. The flaw resides in how the application handles user-supplied input for field grouping parameters, specifically involving the min, max, startTime, and endTime attributes defined within FieldGroupDTO objects. These values are intended to define ranges or time windows for data aggregation but were processed with insufficient validation mechanisms.
The technical root cause of this vulnerability lies in the Utils.transGroupFieldToSql function, which is responsible for converting field group definitions into SQL queries. This function accepts free-form string inputs from authenticated users and directly embeds them into generated CASE expressions without performing adequate sanitization or parameterization checks. Because these values are inserted as raw strings rather than being treated as bound parameters, the application fails to distinguish between legitimate data values and malicious code structures. Consequently, an attacker who has valid authentication credentials can inject arbitrary SQL syntax through carefully crafted input fields.
This stored SQL injection vulnerability allows for significant operational impact on the backend database infrastructure. Since the injected payload is persisted within the dataset configuration, it executes every time a chart utilizing that specific field group definition is rendered or queried. This persistence amplifies the risk compared to reflected injections, as exploitation does not require immediate user interaction with the malicious link but rather occurs during routine data visualization tasks. The ability to execute arbitrary SQL commands compromises the confidentiality of sensitive data by allowing unauthorized extraction, undermines integrity through potential modification or deletion of records, and threatens availability via disruptive queries that may cause database performance degradation or service outages.
From a classification perspective, this vulnerability aligns with CWE-89 Improper Neutralization of Special Elements used in an SQL Command commonly known as SQL Injection. The attack vector leverages authenticated access to manipulate server-side logic, which corresponds to the ATT&CK technique T1059 Command and Scripting Interpreter where attackers use system utilities or scripts to execute commands within a compromised environment. Furthermore, because the injection occurs through stored application data rather than direct request manipulation in real-time, it also reflects aspects of CWE-798 Use of Hard-coded Credentials if authentication bypass is involved, though primarily it remains an input validation failure leading to code execution context switching.
To mitigate this risk and prevent exploitation, organizations must upgrade DataEase to version 2.10.26 or later where the issue has been resolved. The fix likely involves implementing strict parameterized queries for all database interactions involving user-supplied data, ensuring that inputs are treated as literal values rather than executable code components. Additionally, developers should enforce rigorous input validation on both client and server sides to reject any characters or sequences commonly associated with SQL injection attempts such as single quotes, semicolons, and comment markers unless they are part of a validated whitelist pattern. Regular security audits and static application security testing focused on dynamic query construction practices will further reduce the likelihood of similar vulnerabilities in future releases.