CVE-2026-55858
Java vulnerability analysis and mitigation

Overview

CVE-2026-55858 is a charset-confusion vulnerability (Inappropriate Encoding for Output Context) in MariaDB Connector/J (org.mariadb.jdbc:mariadb-java-client), the Java JDBC driver for MariaDB and MySQL databases. The connector assumes the connection character set is always UTF-8, but a server can change character_set_client mid-session to a non-UTF-8 encoding via SET NAMES, stored routines, triggers, server configuration, or a hostile server. This mismatch causes silent data corruption and can defeat byte-wise SQL escaping, potentially enabling SQL injection. Affected versions are all releases prior to 2.7.14, 3.0.0-alpha through 3.3.4, 3.4.0 through 3.4.2, and 3.5.0 through 3.5.8. It was disclosed on July 9, 2026, with patches published August 28, 2026, and carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory).

Technical details

The root cause is CWE-838 (Inappropriate Encoding for Output Context): the driver encodes and decodes all protocol text and performs client-side escaping under the fixed assumption that the connection character set is UTF-8. The MariaDB server can report a mid-session character_set_client change via OK-packet session-state tracking, but the unpatched driver ignores this signal and continues operating as if UTF-8 is in effect. When the server switches to a multi-byte non-UTF-8 encoding (e.g., big5, gbk), the driver's byte-wise quoting and escaping logic no longer correctly identifies quote characters, creating the classic charset-confusion primitive that can be leveraged for SQL injection. The fix adds tracking of character_set_client in session-state variables and, after connection initialization, rejects any charset change to a value other than utf8, utf8mb3, or utf8mb4 by throwing SQLNonTransientConnectionException with SQLState 08000 and closing the socket (GitHub Advisory, Patch Commit).

Impact

The primary impact is a high-severity integrity risk: an attacker who can influence the server's character_set_client mid-session can cause the driver's SQL escaping to silently fail, potentially enabling SQL injection attacks against the application's database. Additionally, any session where the charset diverges from UTF-8 will experience silent data corruption, as the driver writes UTF-8 bytes that the server interprets under a different encoding. There is no direct confidentiality or availability impact per the CVSS scoring, but successful SQL injection could lead to unauthorized data access or modification depending on the application's privilege level (GitHub Advisory).

Exploitability

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.344%, reflecting a low near-term exploitation probability. Exploitation requires high attack complexity — the attacker must be able to trigger a mid-session charset change on the server side, which may require access to execute SQL commands, control over a stored routine or trigger, or the ability to act as a hostile server (GitHub Advisory).

Exploitation steps

  1. Identify a target application: Locate a Java application using MariaDB Connector/J (versions prior to 2.7.14, 3.3.5, 3.4.3, or 3.5.9) connected to a MariaDB or MySQL server with session-state tracking enabled.
  2. Trigger a mid-session charset change: Cause the server to change character_set_client to a non-UTF-8 multi-byte encoding (e.g., big5 or gbk) during an active session. This can be achieved via a SET NAMES big5 command executed through a stored procedure, trigger, or by controlling server configuration. In a hostile-server scenario, the server itself can send a crafted OK-packet with session-state tracking data indicating a charset change.
  3. Exploit charset confusion: Once the server interprets bytes under the new encoding (e.g., big5), craft input containing a multi-byte sequence whose second byte is 0x27 (the ASCII single-quote character). The driver, still operating in UTF-8 mode, will not recognize this as a quote and will not escape it, allowing the quote to reach the server unescaped.
  4. Inject SQL: The unescaped quote character breaks out of the intended SQL string context, enabling injection of arbitrary SQL commands (e.g., ' OR 1=1 --) that the server executes with the application's database privileges (GitHub Advisory).

Indicators of compromise

  • Logs: Application logs showing SQLNonTransientConnectionException with SQLState 08000 and a message containing "Connection character set was changed" — this indicates the patched driver detected and blocked an attempted charset change.
  • Database Logs: MariaDB/MySQL general query logs showing SET NAMES <non-utf8-charset> (e.g., SET NAMES big5, SET NAMES gbk) executed mid-session, especially from application service accounts that would not normally issue such commands.
  • Network: Unexpected OK-packets from the database server containing session-state tracking data that modifies character_set_client to a non-UTF-8 value, which may indicate a hostile or misconfigured server.
  • Application Behavior: Unexplained data corruption in database records, particularly with string fields containing multi-byte characters, which may indicate the charset mismatch was active before patching.

Mitigation and workarounds

Upgrade MariaDB Connector/J to a patched release: 2.7.14 (for 2.x branch), 3.3.5 (for 3.0/3.1/3.2/3.3.x branches), 3.4.3 (for 3.4.x branch), or 3.5.9 (for 3.5.x branch). The vendor states there is no reliable application-level workaround for unpatched versions. As a defense-in-depth measure, server-side controls can be implemented to prevent mid-session charset changes by restricting the SET NAMES command via database user privileges or stored procedure permissions. Organizations using connection pooling should ensure pools are refreshed after upgrading the connector (GitHub Advisory).

Community reactions

The vulnerability was reported by security researcher Yalguun Tumenkhuu (@fg0x0) and credited in the official GitHub Security Advisory. HeroDevs published a blog post covering this CVE alongside related MariaDB Connector vulnerabilities (CVE-2026-55856 through CVE-2026-55860 and CVE-2026-61700) in the context of Spring Boot applications, indicating community awareness of the broader connector security posture (HeroDevs Blog). BrinzTech also published a breach alert specifically covering this vulnerability (BrinzTech Alert).

Additional resources


SourceThis report was generated using AI

Related Java vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-49832HIGH8
  • Java logoJava
  • org.dspace:dspace-api
NoYesSep 02, 2026
CVE-2026-49833MEDIUM5.5
  • Java logoJava
  • org.dspace:dspace-api
NoYesSep 02, 2026
CVE-2026-49831MEDIUM5.5
  • Java logoJava
  • org.dspace:dspace-api
NoYesSep 02, 2026
CVE-2026-55867MEDIUM5.3
  • Java logoJava
  • org.graylog2:graylog2-server
NoYesAug 28, 2026
CVE-2026-49830MEDIUM4.4
  • Java logoJava
  • org.dspace:dspace-api
NoYesSep 02, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management