CVE-2026-55858 in MariaDB Connector
Summary
by MITRE • 08/29/2026
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, the connector encodes and decodes protocol text and performs client-side escaping under the assumption that the connection character set is UTF-8. The server can report a mid-session change to character_set_client through OK-packet session-state tracking, including a change caused by SET NAMES, a stored routine or trigger, server configuration, or a hostile server. If character_set_client changes to a non-UTF-8 value, the driver continues to read and write UTF-8 while the server interprets the same bytes under another encoding, causing silent data corruption and a client/server charset-confusion mismatch that can defeat byte-wise quoting or escaping. The fix accepts only utf8, utf8mb3, or utf8mb4 after initialization; any other value causes SQLException with SQLState 08000 and closes the connection. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The MariaDB Connector/J serves as a critical bridge for Java-based applications seeking to interact with MariaDB and MySQL database servers. A significant security vulnerability exists in versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9 of this connector library. The core flaw stems from an incorrect assumption regarding the character set used for communication between the client driver and the database server. Specifically, the connector encodes and decodes protocol text while performing client-side escaping under the strict presumption that the connection character set is UTF-8. This design choice creates a dangerous mismatch if the actual character set changes during the session lifecycle without the driver properly adapting its encoding logic to match the new setting.
The vulnerability manifests when the server reports a mid-session change to the character_set_client variable through OK-packet session-state tracking mechanisms. Such changes can be triggered by various factors, including explicit SQL commands like SET NAMES, execution of stored routines or triggers that alter session variables, modifications in server configuration, or potentially malicious actions initiated by a hostile database server. When the character set shifts from UTF-8 to any non-UTF-8 value, the driver continues to read and write data using UTF-8 encoding rules. However, the server interprets these same byte sequences according to the new, different encoding standard. This discrepancy leads to silent data corruption because the bytes are interpreted differently by each party involved in the communication channel.
This charset-confusion mismatch has severe operational implications for application security and integrity. Most critically, it can defeat byte-wise quoting or escaping mechanisms that rely on consistent character interpretation. If an attacker can induce a change in the client character set to a multi-byte encoding such as GBK or Big5, they may be able to bypass input validation filters designed to prevent SQL injection attacks. By exploiting the mismatch between how the driver escapes special characters and how the server parses them, an adversary could inject malicious SQL commands that appear valid under one encoding but are interpreted differently by the database engine. This represents a classic case of character set confusion leading to injection vulnerabilities, undermining the primary defense mechanism against code injection in many legacy or improperly configured systems.
From a classification perspective, this vulnerability aligns with CWE-175: Improper Handling of Multiple Encoding Schemes and CWE-89: SQL Injection via Character Set Confusion. In terms of attack vectors, it relates to ATT&CK techniques involving input validation bypasses where the attacker exploits differences in how data is processed by different components within a system architecture. The lack of strict enforcement on character set consistency allows for subtle manipulation that standard static analysis tools might miss because the code appears syntactically correct under its assumed UTF-8 context.
To mitigate this risk, users must upgrade to MariaDB Connector/J versions 2.7.14, 3.3.5, 3.4.3, or 3.5.9 and later. These updated releases implement a strict validation policy that accepts only utf8, utf8mb3, or utf8mb4 character sets after initialization. If any other value is detected during the session state tracking process, the driver now throws an SQLException with SQLState 08000 and immediately closes the connection. This proactive approach prevents the dangerous charset mismatch from occurring by refusing to operate under ambiguous encoding conditions. Organizations relying on these connectors should verify their dependency versions and ensure that database configurations do not inadvertently trigger character set changes during active sessions, thereby maintaining a consistent UTF-8 environment for secure data transmission.