CVE-2026-55859
Patch Available.
This Vulnerability has been fixed in the Never-Ending Support (NES) version offered by HeroDevs.
Overview
MariaDB Connector/R2DBC is MariaDB's non-blocking client for MariaDB and MySQL databases, written in 100% Java. It implements the Reactive Relational Database Connectivity (R2DBC) API, so reactive applications, including those built on Spring Data R2DBC, can connect to and query MariaDB without blocking threads. It is distributed as the Maven artifact org.mariadb:r2dbc-mariadb.
A command injection vulnerability (CVE-2026-55859) has been identified in the session state tracking of MariaDB Connector/R2DBC, which allows a hostile server, or server-side state such as a stored routine, trigger or configuration, to switch the connection's character_set_client to a non-UTF-8 charset mid-session while the driver keeps exchanging UTF-8. The driver and server then interpret the same bytes under different encodings, which silently corrupts data and can defeat byte-wise quoting and escaping, the charset confusion class that can lead to SQL injection.
Per OWASP: A SQL injection attack consists of insertion or "injection" of a SQL query via the input data from the client to the application.
This issue affects multiple versions of MariaDB Connector/R2DBC.
Details
Module Info
- Product: MariaDB Connector/R2DBC
- Affected packages:
org.mariadb:r2dbc-mariadb - Affected versions: <1.2.3, >=1.3.0 <1.3.1, >=1.4.0 <1.4.1
- GitHub repository: https://github.com/mariadb-corporation/mariadb-connector-r2dbc
- Published packages: https://central.sonatype.com/artifact/org.mariadb/r2dbc-mariadb
- Package manager: Maven
- Fixed in:
- OSS MariaDB Connector/R2DBC 1.2.3, 1.3.1, 1.4.1
- NES for MariaDB Connector/R2DBC v1.1.4
Vulnerability Info
This Medium-severity vulnerability is found in the org.mariadb:r2dbc-mariadb package in MariaDB Connector/R2DBC before 1.2.3, 1.3.x before 1.3.1 and 1.4.x before 1.4.1. The driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. The server can announce a change of character_set_client mid-session through the session state tracking data it appends to OK packets, for example after a SET NAMES run by a stored routine or trigger, through server configuration, or because the server itself is hostile.
OkPacket.decode reads these SESSION_TRACK_SYSTEM_VARIABLES entries but only acts on the transaction isolation variables. A character_set_client entry falls through the switch, so the driver accepts the new charset silently and has no way to reject it:
case StateChange.SESSION_TRACK_SYSTEM_VARIABLES:
ByteBuf sessionVariableBuf = BufferUtils.readLengthEncodedBuffer(stateInfo);
String variable = BufferUtils.readLengthEncodedString(sessionVariableBuf);
String value = BufferUtils.readLengthEncodedString(sessionVariableBuf);
logger.debug("System variable change : {} = {}", variable, value);
switch (variable) {
case "transaction_isolation":
case "tx_isolation":
switch (value) {
// ... set the isolation level
}
}
break;After such a switch the driver keeps writing query text and parameters as UTF-8 while the server decodes them under the new charset, and keeps decoding results as UTF-8. Values are stored and returned in a different form from the one the application sent, without any error. Because quoting and escaping operate on UTF-8 bytes, a client and server that disagree on a multi-byte encoding can also defeat byte-wise quoting and escaping, which is the charset confusion class that can lead to SQL injection.
Mitigation
Only recent release series of MariaDB Connector/R2DBC are supported by MariaDB plc. Older release series are End-of-Life and will not receive updates addressing this issue. For more information, see here.
Users of the affected components should apply one of the following mitigations:
- Upgrade affected applications to a currently supported release of MariaDB Connector/R2DBC that contains the fix.
- Leverage a commercial support partner like HeroDevs for post-EOL security support.
Credits
- Yalguun Tumenkhuu (finder)