CVE-2026-55859

MediumCVSS 5.9

Published: 28/08/2026(UTC)Translated: 29/08/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.23%

14th percentile - higher than 14% of all known CVEs

Summary

MariaDB Connector/R2DBC prior to 1.4.1 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.

Risk Assessment

Risk of silent data corruption and potential bypass of SQL protections, leading to unauthorized access or data modification.

Recommendation

Upgrade to version 1.4.1 which only accepts utf8, utf8mb3, or utf8mb4 after initialization; any other value closes the connection.

Other vulnerabilities in MariaDB Connector/R2DBC

CVE-2026-55860Medium
MariaDB Connector/R2DBC prior to 1.4.1 does not gate clear-text password authentication plugins on transport encryption. A hostile or man-in-the-middle MariaDB server can send an AuthSwitchRequest naming mysql_clear_password or dialog (PAM) over a plain-TCP unencrypted connection, and AuthenticationFlow permits ClearPasswordPluginFlow or PamPluginFlow to return the user's password as cleartext bytes on the wire. The disclosed credentials can subsequently be used to authenticate directly to the database server.

Original NVD description (English source)

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.