CVE-2026-55859: MariaDB Connector/R2DBC: Inappropriate Encoding for Output Context and Improper Encoding or Escaping of Output in org.mariadb:r2dbc-mariadb
Summary
The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change charactersetclient mid-session to a non-UTF-8 charset, after which the driver and server interpret the same bytes under different encodings, causing silent data corruption and a client/server charset-confusion mismatch.
Details
The driver encodes and decodes all character data on the assumption that the connection character set is UTF-8. The server can, however, announce a change of charactersetclient mid-session through the OK-packet session-state-tracking mechanism, for example via a SET NAMES … run by a stored routine or trigger, by server configuration, or by a hostile server.
If the new charset is not UTF-8, the driver continues to read and write UTF-8 while the server interprets the same bytes under a different encoding. The result is silent data corruption and a client/server charset-confusion mismatch. Charset confusion of this kind is also the primitive that can defeat byte-wise quoting/escaping when client and server disagree on a multi-byte encoding.
Am I affected?
You are affected if you use mariadb Connector/R2DBC (org.mariadb:r2dbc-mariadb) below 1.4.1 and a connection can be steered, by a hostile or man-in-the-middle server, or by server-side state such as a stored routine, trigger, or configuration — to switch charactersetclient to a non-UTF-8 value mid-session.
Impact
Silent data corruption and a client/server encoding mismatch once the connection's charset diverges from UTF-8. Because the mismatch undermines the assumption that quoting/escaping operates on UTF-8 bytes, it belongs to the charset-confusion class that can lead to SQL injection.
Patches
Fixed in 1.4.1. Once the connection is fully initialized, any subsequent charset change to a value that is not utf8 / utf8mb3 / utf8mb4 is rejected: the driver raises R2dbcNonTransientResourceException (SQLState 08000) and closes the connection rather than continuing to exchange data under a mismatched encoding. Upgrade to 1.4.1 or later.
Workarounds
There is no reliable application-level workaround; upgrade to 1.4.1 or later.
Credit
Reported by Yalguun Tumenkhuu (@fg0x0).
Other sources
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 charactersetclient 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.mariadb:r2dbc-mariadbto a version that resolves this vulnerability.Fixed in 1.4.1 - Upgrade
Upgrade
org.mariadb:r2dbc-mariadbto a version that resolves this vulnerability.Fixed in 1.4.1 - Configuration
After upgrading, ensure the driver only proceeds when the connection character set is utf8 / utf8mb3 / utf8mb4; if a server attempts to change character_set_client mid-session to a non-UTF-8 value, the driver will raise R2dbcNonTransientResourceException (SQLState 08000) and close the connection instead of continuing data exchange under mismatched encoding.
MariaDB Connector/R2DBC (org.mariadb:r2dbc-mariadb) connection character set after initialization = utf8 / utf8mb3 / utf8mb4 only
Event History
Frequently Asked Questions
What conditions are required for the charset mismatch to occur?
The server must change character_set_client to a non-UTF-8 charset during an active session and announce that change through OK-packet session-state tracking. Examples given include SET NAMES executed by a stored routine or trigger, server configuration, or a hostile server.
What is the practical impact of a mismatch?
The connector continues sending and reading UTF-8 while the server interprets the same bytes using the changed charset. This can silently corrupt data, and the resulting charset confusion can defeat byte-wise quoting or escaping for multi-byte encodings.