CVE-2026-55856 Through 55860 and CVE-2026-61700: MariaDB Connector CVEs in Spring Boot

In July 2026, MariaDB published six security advisories against its two Java database connectors: four for org.mariadb.jdbc:mariadb-java-client (Connector/J) and two for org.mariadb:r2dbc-mariadb. The IDs are CVE-2026-55856, CVE-2026-55857, CVE-2026-55858, and CVE-2026-61700 for Connector/J, and CVE-2026-55859 and CVE-2026-55860 for R2DBC. Each carries a CVSS v3.1 vector and CWE classifications. The records have been unusually slow to propagate: as of August 4, 2026, more than three weeks after publication, none of the six existed in the CVE Program, NVD, OSV.dev, or the global GitHub Advisory Database. Both packages are managed dependencies in the Spring Boot BOM, and while in-life Spring Boot will use updated versions in the next release, End-of-Life versions will not be updated. So whether you found this page because a scanner finally flagged one of these IDs or because you went looking and found nothing, the questions are the same: what each finding actually means, which Spring Boot versions carry affected pins, and which part of the exposure a scanner will miss even after the records propagate.

Running an EOL Spring Boot version that no longer gets dependency updates? See NES for Spring.

‍

The six advisories

All six were published to the mariadb-corporation repositories on GitHub between July 9 and July 10, 2026.

MariaDB published CVSS vectors but no numeric scores. The scores below are computed from the published vectors, not assigned by a CNA.

Declared affected ranges, as written by MariaDB: the four Connector/J advisories list affected versions below 2.7.14 with patched releases 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Both R2DBC advisories list affected versions below 1.4.1, patched in 1.4.1.

‍

What the vulnerabilities actually are

Four of the six are credential-disclosure issues, and they share a theme: authentication plugins that transmit the password in cleartext were not consistently gated on a verified, encrypted transport.

CVE-2026-55856 is the most interesting of the set. When Connector/J runs with sslMode=verify-full or verify-ca, a password, and no pinned serverSslCert or truststore, it deliberately accepts a self-signed certificate at the TLS layer and is supposed to prove server identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint guard exists on the OK-packet path and the auth-switch handler, but not on the initial handshake: HandshakeResponse.encode() builds the mysql_clear_password response before any fingerprint check runs. An active man-in-the-middle presenting a self-signed certificate and naming mysql_clear_password as the initial plugin receives the database password in cleartext. The connection is torn down moments later, but the credential is already gone. This defeats the exact protection the developer opted into.

CVE-2026-55857 is the same failure class on a different path. The mysql_clear_password plugin refuses to send a password over plain TCP, but the sibling PAM handler (SendPamAuthPacketFactory, server plugin name dialog) never inherited that secure-transport gate. A hostile or on-path server can issue an Authentication Switch Request for dialog over plain TCP and the driver replies with the password in cleartext. Reachable in the default configuration.

CVE-2026-55860 is the R2DBC analog, and its root cause is architectural: the driver's AuthenticationPlugin interface had no way for a plugin to declare that it requires a secure connection, so clear-text plugins ran regardless of transport encryption.

CVE-2026-55858 and CVE-2026-55859 are a charset-confusion pair, one per connector. Both drivers encode and decode all character data assuming the connection charset is UTF-8. A server can change character_set_client mid-session (via a SET NAMES in a stored routine or trigger, server configuration, or a hostile server), after which driver and server interpret the same bytes under different encodings. The direct result is silent data corruption. The more worrying implication is that charset confusion is the classic primitive for defeating byte-wise quoting and escaping, which is why these carry CWE-838 rather than being filed as reliability bugs.

CVE-2026-61700 is the narrowest. Connector/J does not enforce allowLocalInfile=false on server-initiated LOCAL INFILE requests, so a rogue or on-path server can trigger the file transmission even when the application disabled the mechanism. It is bounded: the server can only request the exact filename the application already named in its own LOAD DATA LOCAL INFILE query, not arbitrary paths. The security guarantee of the flag is not upheld, but this is a defense-in-depth bypass, not an arbitrary file read.

‍

The Spring Boot exposure

Both packages are managed dependencies in the Spring Boot BOM. mariadb-java-client is managed via the mariadb.version property and has been in the BOM since at least Spring Boot 2.4. r2dbc-mariadb is managed via r2dbc-mariadb.version and arrived in Spring Boot 3.1. Here are the default pins, read directly from the spring-boot-dependencies POMs on Maven Central:

While in-life Spring Boot versions will get upgrades in the next scheduled release, End-of-life Spring Boot is also affected and will not receive an update. Spring Boot 2.4, 2.5, and 2.6 pin mariadb-java-client 2.7.4 and 2.7.9 by default. Those fall squarely inside the vendor's own affected range of versions below 2.7.14. All three lines are past their open source support window, so the BOM pin is frozen. Teams on maintained Spring Boot lines can override a managed version with one property. Teams on EOL lines have no upstream mechanism that will ever move that pin, and this is exactly the pattern we documented in our July 2026 Spring Boot managed-dependency patch round-up: the framework goes EOL, but its dependency tree keeps accumulating CVEs.

‍

Exploitability

Being inside a version range is not the same as being exploitable, and all six vectors carry High attack complexity (AC:H). The realistic preconditions:

• CVE-2026-55856 requires sslMode=verify-full or verify-ca with a password and no pinned certificate or truststore, plus an active man-in-the-middle. That configuration is common because it is the documented easy-and-secure default.
• CVE-2026-55857 and CVE-2026-55860 require a hostile or on-path server. CVE-2026-55857 is reachable in the default client configuration when PAM authentication is in use.
• The charset-confusion pair (CVE-2026-55858, CVE-2026-55859) requires the server to change character_set_client mid-session, whether via server-side state or a hostile server.
• CVE-2026-61700 is bounded to the filename the application itself named in its query.

The common thread: every one of these assumes the network path to your database, or the database server itself, is not fully trusted. For a database driver, that is precisely the threat model TLS verification and allowLocalInfile=false exist to address. If you enforce verified TLS with a pinned certificate everywhere and never use PAM or clear-text auth plugins, your practical exposure is limited to the charset-confusion class. If any of your connections cross a network segment you do not fully control, the credential-disclosure issues deserve attention.

‍

Mitigation guidance

Two cautions on the workaround row. Certificate pinning fully addresses CVE-2026-55856 and blocks the MITM variants of the others, but it does not help against a legitimately compromised server. And there is no reliable application-level workaround for the charset-confusion issues; the fix is the patched driver, which rejects any mid-session charset change away from UTF-8 and closes the connection instead of continuing under a mismatched encoding.

‍

The compliance angle

If you operate under a framework that requires auditable vulnerability disposition (PCI DSS 4.0, the EU Cyber Resilience Act, FedRAMP continuous monitoring), this episode is worth a moment of thought beyond the immediate patch. VEX statements and SBOM-based attestations key on upstream identifiers. During the weeks these records existed only as repository advisories, there was nothing to attach a disposition to: you cannot mark a finding as remediated when no tool generates the finding. The exposure existed; the paper trail could not. And the under-scoped 3.x range extends a version of that problem indefinitely, since a pin your tools clear is a pin your audit trail never mentions. The lesson generalizes: treat repository-level advisories from your critical upstream vendors as a monitored source, not just the aggregated databases downstream of them.

‍

Related reading

• Spring Boot managed dependencies still get CVEs after EOL: July 2026 patch round-up
• CVE-2026-54512 & CVE-2026-54513: Jackson PolymorphicTypeValidator bypass, another case of Spring Boot's transitive dependency surface carrying the risk
• CVE-2025-66614 & CVE-2026-24733: two Tomcat vulnerabilities that also affect Spring Boot 2.7

‍

Taking action

Check whether any application pins or inherits mariadb-java-client below 3.5.9 (or below 2.7.14 on the 2.x line) or r2dbc-mariadb below 1.4.1. Grep your dependency reports directly rather than waiting on scanner findings: the 3.x Connector/J pins sit outside the declared ranges and will not be flagged even once the records propagate. Follow this up by investigating if any of those connections cross an untrusted network segment without a pinned server certificate. Third, whether any of your Spring Boot applications are on the 2.4 through 2.6 lines, where the vulnerable pins are inside MariaDB's own declared affected range and will never move.

For maintained Spring Boot versions, the fix is a one-line version override. For EOL versions, the BOM is frozen and the dependency tree underneath it keeps accruing exactly this kind of debt. NES for Spring exists for that second case: patched builds of EOL Spring Boot and its managed dependencies, delivered as drop-in replacements, so a six-advisory gap in a database driver does not require a framework migration to close.