Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T23:17:08.827Z",
  "pubdate": "2026-08-28T23:17:08.827Z",
  "executiveSummary": "MariaDB Connector/J is susceptible to a character set confusion vulnerability that allows for the bypass of security-critical byte-wise quoting and escaping mechanisms.\nThe vulnerability arises due to a discrepancy between the client-side encoding assumptions and the server-side interpretation of the connection character set.\nBy manipulating the character_set_client during a session—via legitimate database operations or malicious server responses—an attacker can induce silent data corruption and potential SQL injection.\nThis flaw affects MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9.\nThe impact is significant, as it effectively neutralizes the driver's ability to safely sanitize user-supplied input, potentially leading to unauthorized data access or modification depending on the application's reliance on client-side escaping.\nExploitation requires the client to connect to a hostile or compromised server, or the existence of an application-layer mechanism that permits the alteration of session character sets.",
  "technicalDetails": "The root cause of this vulnerability is an improper synchronization mechanism between the client driver and the database server regarding session-state tracking for character encodings. MariaDB Connector/J performs client-side data escaping and quoting under the hardcoded assumption that the connection character set remains UTF-8.\nThe vulnerability manifests when the server sends an OK-packet containing session-state information that updates the character_set_client. This update can be triggered by a 'SET NAMES' command, the invocation of stored routines or triggers, specific server configurations, or explicitly malicious responses from a hostile server.\nWhen the server switches the session character set to a non-UTF-8 value, the driver fails to adjust its internal escaping logic accordingly. The driver continues to process and sanitize data using UTF-8 encoding, while the server interprets the resulting byte sequences according to the new, mismatched character encoding.\nThis mismatch creates an effective bypass of security protections; specifically, characters intended to be escaped (e.g., quotes or backslashes) may be interpreted by the server as literal characters or as part of a different encoding sequence, allowing attackers to inject malicious SQL commands that the driver previously deemed safe.\nThe attack flow begins with the establishment of a database connection. An attacker, controlling the server or influencing session state, triggers a change in the character_set_client. Once the mismatch is established, the attacker sends specially crafted inputs. Because the client-side escaping logic operates on the assumption of UTF-8, it fails to neutralize these inputs under the server's current encoding, resulting in the successful execution of unintended SQL statements.\nThe vulnerability is inherent in the communication protocol handling within the connector component. The absence of validation or enforcement of the character set post-initialization allows the state transition to occur without client-side awareness, leaving the application layer exposed to data corruption and injection vectors.\nThe fix implemented in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9 introduces a strict enforcement policy. The driver now strictly accepts only 'utf8', 'utf8mb3', or 'utf8mb4' character sets following the initialization phase. Any attempt to switch to a different encoding results in a SQLException with SQLState 08000 and an immediate termination of the database connection, thereby preventing the state mismatch from occurring."
}