Description

MariaDB Connector/R2DBC is a non-blocking MariaDB and MySQL client implemented in Java. Prior to 1.4.1, org.mariadb:r2dbc-mariadb encodes and decodes all character data under the assumption that the connection character set is UTF-8. A server can announce a mid-session change to character_set_client through the OK-packet session-state-tracking mechanism, including through SET NAMES executed by a stored routine or trigger, server configuration, or a hostile or man-in-the-middle server. If the new character set is not UTF-8, the driver continues to exchange UTF-8 while the server interprets the same bytes under a different 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 raises R2dbcNonTransientResourceException with SQLState 08000 and closes the connection. This issue is fixed in version 1.4.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T23:17:09.007Z",
  "pubdate": "2026-08-28T23:17:09.007Z",
  "executiveSummary": "A critical character set confusion vulnerability exists in the org.mariadb:r2dbc-mariadb driver prior to version 1.4.1.\nThe vulnerability arises from an incorrect assumption that all character data follows UTF-8 encoding, failing to synchronize with mid-session changes to the connection character set via the OK-packet session-state-tracking mechanism.\nThis flaw allows a malicious or compromised server, or an attacker performing a man-in-the-middle (MITM) attack, to force the driver to misinterpret character data.\nThe primary security impact is the defeat of byte-wise quoting and escaping mechanisms, which can lead to SQL injection vulnerabilities or silent data corruption.\nAffected systems include any Java-based application utilizing the MariaDB Connector/R2DBC library versions 1.4.0 and earlier.\nSuccessful exploitation requires the attacker to have control over the database server response or the ability to intercept and modify the communication stream, effectively forcing a character set negotiation that mismatches the client's expectations.",
  "technicalDetails": "The vulnerability resides in the core communication logic of org.mariadb:r2dbc-mariadb, which manages the serialization and deserialization of character data between the client and the MariaDB server.\nThe root cause is a rigid internal assumption that the connection character set remains exclusively UTF-8 throughout the lifecycle of the session. The driver fails to adequately handle or validate dynamic updates to the 'character_set_client' configuration sent by the server via OK-packet session-state-tracking.\nWhen a session initiates a change in the character set—potentially triggered by server-side configuration, stored routines, triggers, or explicit 'SET NAMES' commands—the driver does not update its internal encoding/decoding logic to match the server's new state. This results in a state of 'charset-confusion'.\nIn a typical attack flow, a malicious or MITM server notifies the driver that the character set has changed to a non-UTF-8 encoding. The driver ignores this signal and continues to transmit data in UTF-8. Because the server is interpreting these bytes according to the newly announced encoding, the underlying mapping of character bytes to SQL commands becomes desynchronized.\nThe most severe security implication is the potential bypass of security controls related to input sanitization. The driver relies on byte-wise quoting and escaping to neutralize input; if the character set used by the driver to escape characters differs from the character set used by the server to interpret those characters, the security logic fails. This can result in malicious payloads being incorrectly interpreted or 'unquoted' by the server, enabling SQL injection.\nThe vulnerability affects all versions of the driver prior to 1.4.1. The remediation implemented in 1.4.1 introduces a strict validation gate: if the server attempts to switch to an encoding other than utf8, utf8mb3, or utf8mb4 after the initial handshake, the driver raises an R2dbcNonTransientResourceException with SQLState 08000 and proactively terminates the connection to prevent further data corruption or security bypasses."
}