What is the CVSS score of CVE-2026-32939?

CVE-2026-32939 has a CVSS 3.1 base score of 8.1 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Java are affected by CVE-2026-32939?

DataEase versions 2.10.19 and below contain a locale-dependent validation bypass that allows authenticated users with low privileges to execute arbitrary code or access sensitive data through…. A patch is available.

How to fix or mitigate CVE-2026-32939?

Within 24 hours: Identify all DataEase deployments and their JVM locale configurations, particularly those running in Turkish or similar locale environments; document current versions in use. Within 7 days: Upgrade all DataEase instances to version 2.10.20 or later (first patched release). Within 30 days: Conduct application logs review for suspicious JDBC parameter activity; validate successful patch deployment across all instances; implement locale standardization policy (e.g., enforce UTC/English locale) for all DataEase JVMs going forward.

Java CVE-2026-32939

EUVD-2026-13525 HIGH

Improper Handling of Case Sensitivity (CWE-178)

2026-03-20 security-advisories@github.com

Java Authentication Bypass

8.1

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

8.1 HIGH

AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Analysis Updated

Apr 16, 2026 - 06:20 EUVD-patch-fix

executive_summary

Re-analysis Queued

Apr 16, 2026 - 05:29 backfill_euvd_patch

patch_released

Patch available

Apr 16, 2026 - 05:29 EUVD

2.10.20

EUVD ID Assigned

Mar 20, 2026 - 08:37 euvd

EUVD-2026-13525

Analysis Generated

Mar 20, 2026 - 08:37 vuln.today

CVE Published

Mar 20, 2026 - 04:16 nvd

HIGH 8.1

DescriptionGitHub Advisory

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.

AnalysisAI

DataEase versions 2.10.19 and below contain a locale-dependent validation bypass vulnerability that allows attackers to smuggle dangerous JDBC parameters past security filters. The flaw stems from inconsistent locale handling where DataEase's validation uses the JVM default locale while H2 JDBC always uses English locale, causing Turkish locale environments to misinterpret malicious parameters like 'iNIT' (bypassing blacklist as 'İNIT' while H2 executes it as 'INIT'). This has been confirmed as exploitable in real deployment scenarios and enables authenticated attackers with low privileges to achieve high-impact code execution or data access, though there is no evidence yet of active exploitation or public proof-of-concept.

Technical ContextAI

This vulnerability affects DataEase, an open-source data visualization platform written in Java that uses H2 JDBC for database connectivity. The root cause is CWE-178 (Improper Handling of Case Sensitivity), specifically a locale inconsistency issue. DataEase's security validation uses String.toUpperCase() without an explicit locale parameter, defaulting to the JVM runtime locale, while the H2 JDBC driver consistently normalizes URLs using Locale.ENGLISH. In Turkish locale environments (tr_TR), Java's case conversion rules differ significantly from English—the lowercase 'i' becomes 'İ' (dotted capital I) rather than 'I'. This creates a dangerous discrepancy where malicious JDBC parameters can be crafted to appear benign to DataEase's blacklist filter but still be executed as dangerous commands by the underlying H2 database engine. The affected product according to EUVD is dataease versions prior to 2.10.20.

RemediationAI

Upgrade DataEase to version 2.10.20 or later, which contains the fix for this locale-handling vulnerability as documented in the release notes at https://github.com/dataease/dataease/releases/tag/v2.10.20 and commit 8f1c21834a620d37dafb3fa24605c059d0a5b80d at https://github.com/dataease/dataease/commit/8f1c21834a620d37dafb3fa24605c059d0a5b80d. Organizations unable to immediately upgrade and running DataEase in Turkish or similar locale environments should consider temporarily switching the JVM default locale to English (en_US) using the -Duser.language=en and -Duser.country=US JVM parameters, though this is a workaround and not a complete security solution. Additionally, restrict network access to DataEase instances to trusted IP ranges and implement strict authentication controls to minimize the low-privilege requirement for exploitation. Consult the GitHub security advisory at https://github.com/dataease/dataease/security/advisories/GHSA-pj7p-3m49-52qq for complete vendor guidance.