Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
☕
☕ Maven
Not in CISA KEV
MEDIUM severity

CVE-2026-55859 — r2dbc-mariadb

MEDIUMFix: mariadb-corporation/mariadb-connector-r2dbc@38bad9a

CVE-2026-55859 is a medium-severity (CVSS 5.9) CWE-116 vulnerability in org.mariadb:r2dbc-mariadb. A fix is available for org.mariadb:r2dbc-mariadb — see the affected versions and patch details below.

MariaDB Connector/R2DBC: Inappropriate Encoding for Output Context and Improper Encoding or Escaping of Output in org.mariadb:r2dbc-mariadb

Also known asGHSA-5rqc-86vf-g8r2
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 13, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-55859.

EPSS Exploitation Probability

via FIRST.org ↗
0.5%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs40th percentile — riskier than 40% of all scored CVEsHighest risk
0.00%0.33%0.66%0.99%0.2%0.5%0.5%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-55859 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 385,987 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
☕org.mariadb:r2dbc-mariadb

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client 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 character_set_client 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 character_set_client 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).

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
☕Mavenorg.mariadb:r2dbc-mariadball versions1.4.1org.mariadb:r2dbc-mariadb:1.4.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.mariadb:r2dbc-mariadb, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update org.mariadb:r2dbc-mariadb to 1.4.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-55859 is resolved across your whole dependency graph.

  3. Workarounds

    Until you can upgrade, make sure every query built from user input uses parameterised statements or a prepared-statement API rather than string concatenation, and reduce the database account's privileges so an injected query cannot read or alter data beyond what the feature needs.

Frequently Asked Questions

### Summary The connector encodes and decodes all character data assuming the connection character set is UTF-8. A server can change character_set_client 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 character_set_client mid-session through the OK-packet session-state-tra
O3 Security · Impact-Aware SCA

Is CVE-2026-55859 in your dependencies?

Find it across Maven, including transitive dependencies.

CVE-2026-55859: r2dbc-mariadb — Fixed in 1.4.1