CVE-2026-55859 in MariaDB Connector
Summary
by MITRE • 08/29/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/29/2026
The MariaDB Connector/R2DBC library serves as a non-blocking client implementation for interacting with MariaDB and MySQL databases within Java applications, leveraging reactive programming principles to handle database operations efficiently. A critical security vulnerability exists in versions prior to 1.4.1 regarding the handling of character set negotiations during runtime sessions. The core technical flaw stems from the driver's rigid assumption that all character data exchanged between the client and server is encoded using UTF-8. This assumption holds true only if the initial connection setup explicitly defines UTF-8 as the charset, but it fails to account for dynamic changes in the session state initiated by the database server itself.
The vulnerability manifests through the OK-packet session-state-tracking mechanism, which allows a MariaDB or MySQL server to announce mid-session modifications to the character_set_client variable. Such changes can be triggered legitimately through stored routines, triggers, or specific server configurations that execute SET NAMES commands. However, this same mechanism can also be exploited by a hostile actor controlling the database server or via a man-in-the-middle attack where an intermediary intercepts and alters session parameters. When such a change occurs to a character set other than UTF-8, the driver continues to encode outgoing data as UTF-8 while simultaneously decoding incoming data under that same assumption. Meanwhile, the server interprets these identical byte sequences using its newly announced, different encoding standard.
This discrepancy results in silent data corruption because the bytes interpreted by the client do not match their semantic meaning when processed by the server under a different charset mapping. More critically for security operations, this character set confusion can defeat byte-wise quoting or escaping mechanisms employed to prevent SQL injection attacks. If an attacker can manipulate the session's character set to one that maps certain special characters differently than UTF-8 does, they may bypass input validation logic that relies on specific byte patterns associated with safe encoding in UTF-8. This leads to a classic charset confusion vulnerability where the application believes it is sanitizing inputs correctly based on UTF-8 rules, but the database processes them under a different set of parsing rules, potentially allowing malicious payloads to execute.
From an industry standards perspective, this issue aligns closely with CWE-175: Improper Handling of Multiple Encoding Types and CWE-693: Protection Mechanism Failure related to character encoding mismatches. In terms of the MITRE ATT&CK framework, this vulnerability facilitates techniques associated with Input Validation Bypass (T1190) and potentially Data Injection (T1190), as the attacker leverages server-side state manipulation to alter how input data is parsed by the database engine. The lack of strict enforcement on charset changes allows an adversary to exploit the gap between application-level expectations and database-level interpretation, undermining the integrity and confidentiality of stored data.
The resolution implemented in version 1.4.1 addresses this flaw by enforcing a strict policy that accepts only utf8, utf8mb3, or utf8mb4 character sets after initialization. If any other value is announced by the server during the session state tracking process, the driver immediately raises an R2dbcNonTransientResourceException with SQLState 08000 and closes the connection. This proactive rejection prevents the application from continuing to operate under a compromised or mismatched encoding context, thereby eliminating the possibility of silent data corruption and charset-based injection attacks. Organizations utilizing this connector must upgrade to version 1.4.1 or later to ensure that character set negotiations remain secure and consistent throughout the database session lifecycle.