CVE-2026-32939
Received Received - Intake
Locale-Based SQL Injection Bypass in DataEase JDBC Validation

Publication date: 2026-03-20

Last updated on: 2026-03-23

Assigner: GitHub, Inc.

Description
DataEase is an open source data visualization analysis tool. Versions 2.10.19 and below have inconsistent Locale handling between the JDBC URL validation logic and the H2 JDBC engine's internal parsing. DataEase uses String.toUpperCase() without specifying an explicit Locale, causing its security checks to rely on the JVM's default runtime locale, while H2 JDBC always normalizes URLs using Locale.ENGLISH. In Turkish locale environments (tr_TR), Java converts the lowercase letter i to Δ° (dotted capital I) instead of the standard I, so a malicious parameter like iNIT becomes Δ°NIT in DataEase's filter (bypassing its blacklist) while H2 still correctly interprets it as INIT. This discrepancy allows attackers to smuggle dangerous JDBC parameters past DataEase's security validation, and the issue has been confirmed as exploitable in real DataEase deployment scenarios running under affected regional settings. The issue has been fixed in version 2.10.20.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-20
Last Modified
2026-03-23
Generated
2026-05-07
AI Q&A
2026-03-20
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
dataease dataease to 2.10.20 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-178 The product does not properly account for differences in case sensitivity when accessing or determining the properties of a resource, leading to inconsistent results.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': 'CVE-2026-32939 is a remote code execution (RCE) vulnerability in DataEase versions 2.10.19 and below caused by inconsistent Locale handling during JDBC URL validation.'}, {'type': 'paragraph', 'content': "DataEase uses Java's String.toUpperCase() method without specifying an explicit Locale, causing its validation logic to depend on the JVM's default runtime locale. Meanwhile, the H2 JDBC engine always normalizes URLs using Locale.ENGLISH."}, {'type': 'paragraph', 'content': 'In Turkish locale environments (tr_TR), the uppercase conversion of the letter \'i\' results in \'Δ°\' (Latin Capital Letter I with Dot), whereas Locale.ENGLISH conversion results in \'I\'. This discrepancy allows malicious parameters like "iNIT" to be transformed differently by DataEase and H2, enabling attackers to bypass DataEase\'s blacklist-based JDBC URL validation.'}, {'type': 'paragraph', 'content': 'An attacker can submit a crafted H2 JDBC URL containing parameters such as "iNIT=RUNSCRIPT" which bypasses DataEase\'s security filter under Turkish locale settings but is correctly interpreted by H2, leading to remote code execution on the server.'}, {'type': 'paragraph', 'content': 'This issue has been confirmed exploitable in real deployment scenarios and was fixed in DataEase version 2.10.20.'}] [1]


How can this vulnerability impact me? :

[{'type': 'paragraph', 'content': "This vulnerability allows an attacker to bypass DataEase's JDBC URL validation and execute arbitrary code remotely on the server running DataEase."}, {'type': 'paragraph', 'content': 'By exploiting the locale mismatch, an attacker can inject malicious JDBC parameters that trigger harmful commands such as RUNSCRIPT, potentially leading to full remote code execution (RCE).'}, {'type': 'paragraph', 'content': 'The impact includes unauthorized control over the affected system, data compromise, and potential disruption of services.'}] [1]


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for suspicious JDBC URL parameters that bypass DataEase\'s validation, especially under Turkish locale settings. Specifically, look for JDBC URLs containing parameters like "iNIT=RUNSCRIPT" or similar variations that exploit locale-based uppercase conversion discrepancies.'}, {'type': 'paragraph', 'content': 'Detection can involve inspecting DataEase datasource validation logs or network traffic for JDBC URLs with unusual or blacklisted parameters that should normally be blocked but appear due to locale issues.'}, {'type': 'paragraph', 'content': 'While no explicit commands are provided in the resources, you can use network monitoring tools (e.g., tcpdump, Wireshark) or log analysis commands (e.g., grep) to search for suspicious JDBC URL patterns in your DataEase logs or network captures.'}, {'type': 'list_item', 'content': "Example command to search logs for suspicious parameters: grep -i 'iNIT=RUNSCRIPT' /path/to/dataease/logs/*"}, {'type': 'list_item', 'content': 'Use locale-aware string inspection in Java or scripts to detect mismatches in uppercase conversion of JDBC parameters.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

[{'type': 'paragraph', 'content': 'The primary and recommended mitigation is to upgrade DataEase to version 2.10.20 or later, where this vulnerability has been fixed.'}, {'type': 'paragraph', 'content': 'The fix includes proper handling of Locale in JDBC URL validation and adding additional disallowed JDBC parameters (such as "IniFile") to prevent bypass.'}, {'type': 'paragraph', 'content': 'If upgrading immediately is not possible, consider running the JVM with a fixed Locale setting (e.g., Locale.ENGLISH) to avoid the Turkish locale uppercase conversion issue, although this is a temporary workaround.'}] [1, 2, 3]


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart