
Cloud Vulnerability DB
A community-led vulnerabilities database
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).
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).
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).
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).
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.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.' OR 1=1 --) that the server executes with the application's database privileges (GitHub Advisory).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.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.character_set_client to a non-UTF-8 value, which may indicate a hostile or misconfigured server.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).
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).
Source: This report was generated using AI
Free Vulnerability Assessment
Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.
Get a personalized demo
"Best User Experience I have ever seen, provides full visibility to cloud workloads."
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
"We know that if Wiz identifies something as critical, it actually is."