CVE-2026-55856: MariaDB Connector/J Auth Bypass Vulnerability

CVE-2026-55856 Overview

CVE-2026-55856 is a credential disclosure vulnerability in MariaDB Connector/J, the Java Database Connectivity (JDBC) driver used to connect Java applications to MariaDB and MySQL databases. The flaw allows an active man-in-the-middle attacker or hostile server to capture cleartext database passwords during the initial TLS handshake. The vulnerability exists because the initial handshake path fails to validate the certificate fingerprint before sending a mysql_clear_password authentication response. Affected releases include versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9.

Critical Impact
An attacker positioned between a Java application and the database can present a self-signed certificate, force the mysql_clear_password plugin, and receive the full database password before the connection is rejected.

Affected Products

MariaDB Connector/J versions prior to 2.7.14
MariaDB Connector/J versions 3.x prior to 3.3.5, 3.4.3, and 3.5.9
Java applications using sslMode=verify-full or sslMode=verify-ca without serverSslCert or trustStore configured

Discovery Timeline

2026-08-28 - CVE-2026-55856 published to NVD
2026-08-31 - Last updated in NVD database

Technical Details for CVE-2026-55856

Vulnerability Analysis

The vulnerability, classified as [CWE-522] Insufficiently Protected Credentials, resides in the client authentication flow of MariaDB Connector/J. When a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and omits serverSslCert or trustStore configuration, the driver falls back to an ephemeral trust manager via fallbackToSystemTrustStore=true. This ephemeral trust manager accepts an untrusted self-signed certificate and records its certFingerprint for later identity binding.

The OK-packet and authentication-switch paths correctly enforce the certificate fingerprint check. However, the initial-handshake path in HandshakeResponse.encode() does not. The driver builds and sends a mysql_clear_password response without verifying certFingerprint != null && !isMitMProof(), the sslMode, or whether the authentication plugin resists man-in-the-middle attacks. The initial path also bypasses the restrictedAuth control.

Root Cause

The root cause is a missing gate on the initial-handshake code path. The certificate fingerprint captured at the TLS layer is not verified against a trusted certificate authority before credentials leave the client. Because the initial HandshakeResponse runs before any fingerprint identity check, a plugin that transmits credentials in cleartext, such as mysql_clear_password, exposes the password to a possibly attacker-controlled server.

Attack Vector

An active man-in-the-middle attacker intercepts the TLS handshake between the Java client and the database server. The attacker presents a self-signed certificate, claims to be MariaDB, and selects mysql_clear_password as the initial authentication plugin. The Java client accepts the certificate via the ephemeral trust manager, encodes the cleartext password into the initial handshake response, and transmits it to the attacker. The connection is later rejected during fingerprint validation, but the password has already been disclosed.

java

// Security patch in StandardClient.java - enforces plugin and transport gating
authPlugin =
    "mysql_clear_password".equals(authenticationPluginType)
        ? new ClearPasswordPlugin()
        : new NativePasswordPlugin();
// A plugin requiring SSL (e.g. mysql_clear_password, which transmits the password in clear
// text) must only run over a secure transport - TLS or a local unix socket, never plain TCP.
if (authPlugin.requireSsl()
    && !context.hasClientCapability(SSL)
    && !(socket instanceof UnixDomainSocket)) {
  throw context
      .getExceptionFactory()
      .create(
          "Cannot use authentication plugin "
              + authenticationPluginType
              + " if SSL is not enabled (a clear-text password plugin requires TLS or a"
              + " local unix socket).",
          "08000");
}
// When the server certificate was accepted at the TLS layer only via fingerprint capture
// (self-signed / "MitM-proof without a CA"), its identity is not yet verified at this point.
// Refuse to send the initial response with a non-MitM-proof plugin, which would otherwise
// leak the password to a possibly attacker-controlled server before the later fingerprint
// identity check runs.
if (certFingerprint != null
    && (!authPlugin.isMitMProof()
        || credential.getPassword() == null
        || credential.getPassword().isEmpty())) {

Source: MariaDB Connector/J Commit 149ec6a

Detection Methods for CVE-2026-55856

Indicators of Compromise

Unexpected TLS certificate fingerprint changes between the JDBC client and MariaDB or MySQL servers
Database connection attempts followed by immediate connection rejection after the initial handshake
Java application logs recording use of mysql_clear_password plugin over connections lacking a configured trustStore or serverSslCert

Detection Strategies

Inventory JDBC configurations for sslMode=verify-full or sslMode=verify-ca combined with missing serverSslCert and trustStore properties
Audit dependency manifests (Maven, Gradle) for mariadb-java-client versions below 2.7.14, 3.3.5, 3.4.3, or 3.5.9
Inspect network telemetry for anomalous TLS certificates presented on MariaDB or MySQL ports (default 3306) from unexpected sources

Monitoring Recommendations

Monitor egress connections from application servers to database endpoints for unexpected certificate authorities or self-signed certificates
Alert on Java application errors indicating authentication rejection after handshake completion
Track configuration drift in JDBC URLs and connection pool settings across development, staging, and production environments

How to Mitigate CVE-2026-55856

Immediate Actions Required

Upgrade MariaDB Connector/J to version 2.7.14, 3.3.5, 3.4.3, or 3.5.9 depending on the branch in use
Configure serverSslCert or trustStore explicitly for every JDBC connection using sslMode=verify-full or sslMode=verify-ca
Rotate database passwords for any accounts that may have connected through an untrusted network path before patching

Patch Information

MariaDB has published fixes in Release 3.4.3 and Release 3.5.9. Full technical details are available in GHSA-g9jj-cgmh-9f38 and the tracking issue CONJ-1325. The patches enforce that cleartext authentication plugins run only over verified TLS or Unix domain sockets, and reject the initial handshake when the server certificate was accepted only via fingerprint capture.

Workarounds

Explicitly configure serverSslCert pointing to a known-good server certificate file
Configure a Java trustStore containing the authoritative certificate authority for the database server
Disable fallbackToSystemTrustStore where possible and require certificate authority validation for all database connections
Restrict authentication plugins via the restrictedAuth connection property to exclude mysql_clear_password

bash

# Example: hardened JDBC URL enforcing full certificate validation
jdbc:mariadb://db.example.com:3306/appdb?sslMode=verify-full&serverSslCert=/etc/pki/mariadb/server-ca.pem&restrictedAuth=mysql_native_password,caching_sha2_password