CVE-2026-32939
Dataease ≤ 2.10.20
Raw vector
CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-32939 is a high-severity Improper Handling of Case Sensitivity (CWE-178) vulnerability in Dataease Dataease. Its CVSS base score is 7.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Masquerading (T1036); ranked at the 37th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog; a public proof-of-concept is referenced.
The strongest mitigations our analysis identified map to AC-24 (Access Control Decisions) and AC-3 (Access Enforcement) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-32939 affects DataEase, an open source data visualization analysis tool, in versions 2.10.19 and prior. The vulnerability stems from inconsistent locale handling in JDBC URL validation logic compared to the H2 JDBC engine's internal parsing. DataEase applies String.toUpperCase() without specifying an explicit locale, relying on the JVM's default runtime locale, while H2 JDBC normalizes URLs using Locale.ENGLISH. In Turkish locale environments (tr_TR), this causes lowercase 'i' to convert to 'İ' (dotted capital I) in DataEase's security checks, allowing bypass of blacklisted parameters.
Remote attackers with no privileges (AV:N/PR:N) can exploit this under high attack complexity (AC:H), crafting malicious JDBC parameters like "iNIT" that appear as "İNIT" in DataEase's filter (evading the blacklist) but are interpreted by H2 as "INIT". Successful exploitation smuggles dangerous parameters past validation, potentially leading to high confidentiality, integrity, and availability impacts (C:H/I:H/A:H) with CVSS score 8.1 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). The issue, tied to CWE-178, has been confirmed exploitable in real DataEase deployments running under affected regional settings.
The vulnerability is fixed in DataEase version 2.10.20. Relevant advisories and patches are detailed in the GitHub security advisory (GHSA-pj7p-3m49-52qq), the release notes for v2.10.20, and the fixing commit (8f1c21834a620d37dafb3fa24605c059d0a5b80d). Security practitioners should upgrade to 2.10.20 or later and verify JVM locale configurations in deployments.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-13525
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Applying access control decisions to each request depends on accurate property determination that accounts for case differences.
Correct enforcement of authorizations for resource access structurally requires consistent case-sensitive handling of identifiers to avoid incorrect decisions.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices can catch and prevent case-sensitivity flaws during code review or testing, but fixing one CWE achieves negligible coverage of the broad control.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure SDLC practices should include case-sensitivity requirements in design and coding standards.
Application security requirements must specify case handling for identifiers and paths.
Architecture principles should enforce canonical, case-aware resource naming.
Secure coding guidelines must mandate explicit case handling to prevent inconsistent lookups.
Access-control rules that ignore case can allow unintended resource access.
Authentication logic must treat identifiers consistently to avoid bypass via case differences.