CVE-2026-33207: DataEase SQL Injection Vulnerability

CVE-2026-33207 Overview

CVE-2026-33207 is a SQL Injection vulnerability affecting DataEase, an open-source data visualization and analytics platform. The vulnerability exists in the /datasource/getTableField endpoint where the getTableFiledSql method in CalciteProvider.java incorporates the tableName parameter directly into SQL query strings using String.format without proper parameterization or sanitization. An authenticated attacker can exploit this flaw to execute arbitrary SQL commands, enabling error-based extraction of sensitive database information.

Critical Impact

Authenticated attackers can bypass table name validation by registering a malicious API datasource, then execute arbitrary SQL commands to extract sensitive database information.

Affected Products

• DataEase versions 2.10.20 and below

Discovery Timeline

• April 16, 2026 - CVE-2026-33207 published to NVD
• April 16, 2026 - Last updated in NVD database

Technical Details for CVE-2026-33207

Vulnerability Analysis

This SQL Injection vulnerability (CWE-89) stems from improper handling of user-controlled input in the DataEase platform's datasource management functionality. While DatasourceServer.java includes validation logic to verify that a table name exists within the datasource, attackers can circumvent this security control through a clever exploitation technique.

The attack involves first registering an API datasource with a malicious deTableName value. This malicious table name is subsequently returned by the getTables function and passes the validation check, effectively bypassing the intended security control. Once past validation, the unsanitized table name is incorporated directly into SQL queries via String.format, allowing injection of arbitrary SQL statements.

The vulnerability is network-accessible and requires low attack complexity with no user interaction, though authentication is required. Successful exploitation can result in high confidentiality and integrity impacts, enabling attackers to extract sensitive data or manipulate database contents.

Root Cause

The root cause is the use of String.format for SQL query construction in the getTableFiledSql method within CalciteProvider.java. Rather than using parameterized queries or prepared statements, the method directly concatenates user-supplied tableName values into SQL query strings. Combined with an insufficient validation mechanism that can be bypassed through API datasource registration, this creates an exploitable SQL injection vector.

Attack Vector

The attack proceeds through the following stages:

1. An authenticated attacker registers a new API datasource with a malicious deTableName containing SQL injection payloads
2. The malicious table name is stored and returned by the getTables function
3. When the attacker makes a request to /datasource/getTableField using this malicious table name, it passes validation since it exists as a registered table
4. The getTableFiledSql method incorporates the malicious table name directly into SQL queries via String.format
5. The injected SQL commands execute against the database, allowing error-based data extraction

This bypass technique demonstrates how validation logic that checks for table existence can be circumvented when attackers can control the list of valid values through a separate registration mechanism.

Detection Methods for CVE-2026-33207

Indicators of Compromise

• Unusual API datasource registrations with suspicious deTableName values containing SQL syntax
• HTTP requests to /datasource/getTableField endpoint with anomalous table name parameters
• Database error messages in application logs indicating SQL syntax errors or injection attempts
• Unexpected database queries containing UNION, SELECT, or other SQL keywords in table name positions

Detection Strategies

• Deploy web application firewall (WAF) rules to detect SQL injection patterns in requests to the /datasource/getTableField endpoint
• Implement database activity monitoring to identify anomalous query patterns or error-based data extraction attempts
• Monitor API datasource registration events for suspicious deTableName values containing SQL metacharacters
• Enable detailed logging on the DataEase application to capture request parameters for forensic analysis

Monitoring Recommendations

• Review application logs for repeated requests to /datasource/getTableField with varying table name parameters
• Monitor for database error messages that may indicate SQL injection probing activity
• Establish baseline patterns for API datasource registrations and alert on deviations
• Track failed database queries that contain unexpected SQL syntax in identifier positions

How to Mitigate CVE-2026-33207

Immediate Actions Required

• Upgrade DataEase to version 2.10.21 or later immediately to remediate this vulnerability
• Review existing API datasource registrations for any suspicious or malicious deTableName entries
• Audit database access logs for evidence of exploitation or data extraction attempts
• Temporarily restrict access to the /datasource/getTableField endpoint if immediate patching is not possible

Patch Information

The DataEase development team has addressed this vulnerability in version 2.10.21. The fix implements proper input sanitization and parameterized queries to prevent SQL injection through the tableName parameter. Organizations should upgrade to this version as soon as possible.

For detailed patch information, refer to the GitHub Release v2.10.21 and the GitHub Security Advisory GHSA-pgh3-rgw3-xjmm.

Workarounds

• Implement network-level access controls to restrict access to the DataEase platform to trusted users only
• Deploy a web application firewall with SQL injection detection rules in front of the DataEase application
• Disable or restrict the API datasource registration feature if not required for business operations
• Apply principle of least privilege to database accounts used by DataEase to limit potential impact

# Example: Restrict access to vulnerable endpoint via nginx
location /datasource/getTableField {
    # Allow only trusted IP ranges
    allow 10.0.0.0/8;
    allow 192.168.0.0/16;
    deny all;
}