CVE-2026-45535: stored SQL injection

CISO Take

DataEase, an open source BI/data-visualization tool used to build dashboards over datasets (including ML/analytics data), fails to escape attacker-controlled `${var}` default values before splicing them into SQL via simple String.replace(), creating a stored SQL injection that fires whenever any user with mere read permission opens the affected dataset. There is no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template yet, so this is not an actively exploited or high-visibility bug today — but the exploitation bar is low (CWE-89, no auth bypass needed beyond standard dataset access) and the blast radius includes any downstream consumer of that dataset's dashboard, not just the attacker who planted the payload. Because DataEase datasets often sit in front of analytics and ML-adjacent data stores, a successful injection can expose or corrupt whatever the dataset's DB connection can reach. Patch to DataEase 2.10.23 immediately; until then, audit who holds dataset-edit permissions (the injection point) and monitor DB logs for anomalous queries originating from the DataEase service account. Detection: review recent SQL-type datasets for unexpected `${...}` variable defaults and diff against the fixed commit's sanitization logic.

Sources: NVD GitHub Advisory ATLAS

What is the risk?

Moderate risk overall. The vulnerability class (stored SQL injection, CWE-89) is well understood and easy to weaponize once an attacker can create or edit a SQL-type dataset, and the trigger condition (any read-permission user viewing the dataset) is low-friction, effectively turning a single low-privilege write into a persistent trap for higher-privilege viewers. Mitigating factors: no public PoC or scanner template exists yet, it's not in CISA KEV, and there's no CVSS/EPSS score to indicate active or imminent mass exploitation. Exposure depends heavily on how permissively an organization grants dataset-creation rights in DataEase — in environments where many users can author datasets, this is effectively an internal privilege-escalation-via-SQLi vector.

How does the attack unfold?

Malicious Dataset Creation

An attacker with dataset-edit permission creates or modifies a SQL-type DataEase dataset, embedding a crafted SQL payload inside a variable's `${var}` defaultValue.

Stored Injection Persists

DataEase's handleVariableDefaultValue() inserts the payload into the dataset's SQL via unescaped String.replace(), persisting it as part of the dataset definition.

Victim Trigger

Any user with only read permission who opens or refreshes the dataset causes DataEase to execute the tainted SQL against the configured database connection.

AML.T0049

Data Impact

The injected SQL executes with the dataset's DB connection privileges, enabling data exfiltration, tampering, or destruction depending on the connection's access scope.

AML.T0036

Malicious Dataset Creation

An attacker with dataset-edit permission creates or modifies a SQL-type DataEase dataset, embedding a crafted SQL payload inside a variable's `${var}` defaultValue.

Stored Injection Persists

DataEase's handleVariableDefaultValue() inserts the payload into the dataset's SQL via unescaped String.replace(), persisting it as part of the dataset definition.

Victim Trigger

Any user with only read permission who opens or refreshes the dataset causes DataEase to execute the tainted SQL against the configured database connection.

AML.T0049

Data Impact

The injected SQL executes with the dataset's DB connection privileges, enabling data exfiltration, tampering, or destruction depending on the connection's access scope.

AML.T0036

How severe is it?

CVSS 3.1

N/A

EPSS

0.4%

chance of exploitation in 30 days

Higher than 31% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What should I do?

1 step

1) Upgrade to DataEase 2.10.23 or later, which fixes the unescaped String.replace() call in SqlparserUtils.handleVariableDefaultValue(). 2) Until patched, restrict dataset creation/edit permissions to trusted users only, since the injection point requires the ability to set a SQL variable's default value. 3) Audit existing SQL-type datasets for suspicious ${var} default values containing SQL metacharacters or unexpected syntax, comparing against the fixed commit (github.com/dataease/dataease/commit/22930a4). 4) Review DB connection accounts used by DataEase and apply least-privilege (read-only, scoped to required tables) so a successful injection has limited blast radius. 5) Monitor DataEase-originated DB queries for anomalies (unexpected UNION/subqueries, out-of-band calls) as a compensating detection control.

What does CISA's SSVC say?

Decision Attend

Exploitation poc

Automatable No

Technical Impact total

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Code Execution Data Extraction Training Data AML.T0036 - Data from Information Repositories AML.T0049 - Exploit Public-Facing Application

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.7.4 - Data quality and integrity for AI systems

NIST AI RMF

MAP-3 - AI system data and third-party components are mapped and assessed for risk

Frequently Asked Questions

What is CVE-2026-45535?

DataEase, an open source BI/data-visualization tool used to build dashboards over datasets (including ML/analytics data), fails to escape attacker-controlled `${var}` default values before splicing them into SQL via simple String.replace(), creating a stored SQL injection that fires whenever any user with mere read permission opens the affected dataset. There is no CVSS score, EPSS data, CISA KEV listing, public exploit, or Nuclei template yet, so this is not an actively exploited or high-visibility bug today — but the exploitation bar is low (CWE-89, no auth bypass needed beyond standard dataset access) and the blast radius includes any downstream consumer of that dataset's dashboard, not just the attacker who planted the payload. Because DataEase datasets often sit in front of analytics and ML-adjacent data stores, a successful injection can expose or corrupt whatever the dataset's DB connection can reach. Patch to DataEase 2.10.23 immediately; until then, audit who holds dataset-edit permissions (the injection point) and monitor DB logs for anomalous queries originating from the DataEase service account. Detection: review recent SQL-type datasets for unexpected `${...}` variable defaults and diff against the fixed commit's sanitization logic.

Is CVE-2026-45535 actively exploited?

No confirmed active exploitation of CVE-2026-45535 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-45535?

1) Upgrade to DataEase 2.10.23 or later, which fixes the unescaped `String.replace()` call in `SqlparserUtils.handleVariableDefaultValue()`. 2) Until patched, restrict dataset creation/edit permissions to trusted users only, since the injection point requires the ability to set a SQL variable's default value. 3) Audit existing SQL-type datasets for suspicious `${var}` default values containing SQL metacharacters or unexpected syntax, comparing against the fixed commit (github.com/dataease/dataease/commit/22930a4). 4) Review DB connection accounts used by DataEase and apply least-privilege (read-only, scoped to required tables) so a successful injection has limited blast radius. 5) Monitor DataEase-originated DB queries for anomalies (unexpected UNION/subqueries, out-of-band calls) as a compensating detection control.

What systems are affected by CVE-2026-45535?

This vulnerability affects the following AI/ML architecture patterns: BI/analytics dashboards, data pipelines, training pipelines.

What is the CVSS score for CVE-2026-45535?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

BI/analytics dashboardsdata pipelinestraining pipelines

MITRE ATLAS Techniques

AML.T0036 Data from Information Repositories

AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.7.4

NIST AI RMF: MAP-3

What are the technical details?

Original Advisory

DataEase is an open source data visualization and analysis tool. Prior to 2.10.23, DataEase SQL-type datasets store attacker-controlled SQL variable defaultValue entries such as ${var} and SqlparserUtils.handleVariableDefaultValue() inserts them with String.replace() without escaping or parameterization, causing stored SQL injection whenever a user with dataset read permission accesses the dataset. This issue is fixed in version 2.10.23.

Exploitation Scenario

An internal user (or compromised low-privilege account) with dataset-authoring rights creates a SQL-type dataset and sets a variable's `defaultValue` to a crafted string like `1; DROP TABLE users;--` or a UNION-based payload designed to exfiltrate rows from another table. Because DataEase inserts this value via unescaped `String.replace()` rather than parameterized binding, the payload becomes part of the executed SQL. Any other user — including an admin or analyst with only read access — who later opens or refreshes that dataset triggers the injected query against the underlying database connection, silently leaking or corrupting data accessible to that connection without the victim taking any unusual action.

Weaknesses (CWE)

CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') Primary CWE-89 Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')

CWE-89 — Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection'): The product constructs all or part of an SQL command using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the intended SQL command when it is sent to a downstream component. Without sufficient removal or quoting of SQL syntax in user-controllable inputs, the generated SQL query can cause those inputs to be interpreted as SQL instead of ordinary user data.

[Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482]. For example, consider using persistence layers such as Hibernate or Enterprise Java Beans, which can provide significant protection against SQL injection if used properly.
[Architecture and Design] If available, use structured mechanisms that automatically enforce the separation between data and code. These mechanisms may be able to provide the relevant quoting, encoding, and validation automatically, instead of relying on the developer to provide this capability at every point where output is generated. Process SQL queries using prepared statements, parameterized queries, or stored procedures. These features should accept parameters or variables and support strong typing. Do not dynamically construct and execute query strings within these features using "exec" or similar functionality, since this may re-introduce the possibility of SQL injection. [REF-867]

Source: MITRE CWE corpus.