CVE-2026-55856: Credential Disclosure via Out-of-Order Handshake in MariaDB Connector/J

MariaDB Connector/J provides database connectivity for Java-based applications. The driver implements a fallback mechanism to facilitate SSL-enabled connections when explicit trust stores or pinned certificates are omitted. When a client connects using sslMode=verify-ca or sslMode=verify-full without a configured trustStore or serverSslCert, the connector defaults to using an ephemeral trust manager.

This trust manager allows the TLS connection to establish with untrusted certificates, storing the SHA-256 certificate fingerprint for later identity validation. The security architecture relies on verifying the fingerprint during subsequent stages, specifically within the OK packet or authentication-switch sequences. This deferred verification model creates an exposure window where the client communicates over an unverified socket.

An active adversary-in-the-middle or a rogue database server can exploit this state by presenting a self-signed TLS certificate. Because the client delays identity verification, the channel is treated as trusted during the early handshake steps. The attacker can then force a cleartext authentication mechanism and receive credentials before the connection is aborted.

The root cause of the vulnerability lies in the out-of-order execution logic in StandardClient.java. During protocol initialization, the database server sends an InitialHandshakePacket indicating its supported capabilities and the preferred initial authentication plugin. If the server demands mysql_clear_password as the initial plugin, the driver prepares a response to satisfy this request.

In vulnerable versions of the driver, HandshakeResponse.encode() is called to construct the client handshake packet. This method processes the database credentials and serializes the raw password into the socket buffer. The driver performs this write operation before verifying whether the remote server certificate matches the stored fingerprint state.

Additionally, this initial handshake path bypasses the driver's restricted authentication settings (restrictedAuth). The client is forced to transmit raw credentials across an unverified connection without executing any of the defensive checks intended to protect sensitive data transfers.

A comparison of the codebase before and after the remediation highlights the implementation of strict sequence gates. In vulnerable versions, HandshakeResponse was instantiated and encoded before the driver initialized the authentication plugin or evaluated the state of the TLS certificate fingerprint.

// VULNERABLE SEQUENCE
new HandshakeResponse(...).encode(writer, context);
authPlugin = "mysql_clear_password".equals(authenticationPluginType)
    ? new ClearPasswordPlugin()
    : new NativePasswordPlugin();
writer.flush();

The patch restructures this logic in StandardClient.java to perform validation prior to encoding and sending the handshake payload. The driver now determines the authentication plugin type beforehand and asserts connection trust properties.

// PATCHED SEQUENCE
authPlugin =
    "mysql_clear_password".equals(authenticationPluginType)
        ? new ClearPasswordPlugin()
        : new NativePasswordPlugin();
 
if (authPlugin.requireSsl()
    && !context.hasClientCapability(SSL)
    && !(socket instanceof UnixDomainSocket)) {
  throw context.getExceptionFactory().create("Plain TCP transport is blocked for cleartext authentication.");
}
 
if (certFingerprint != null
    && (!authPlugin.isMitMProof()
        || credential.getPassword() == null
        || credential.getPassword().isEmpty())) {
  throw context.getExceptionFactory().create("Cannot use cleartext authentication over unverified self-signed certificates.");
}

By verifying certFingerprint != null and checking if authPlugin.isMitMProof() is false, the patched connector prevents the serialization of sensitive credentials over an unverified TLS connection. If a self-signed certificate is in use, the handshake terminates immediately, thwarting credential leakage.

Exploitation of CVE-2026-55856 is achieved by configuring a malicious rogue MySQL/MariaDB server or intercepting the connection as an active proxy. The targeted application must be configured to connect with sslMode=verify-ca or sslMode=verify-full without explicitly providing trust store certificates, enabling the ephemeral fallback behavior.

The rogue server completes the TLS handshake using an arbitrary self-signed certificate, which the client accepts into its temporary storage. Following the TLS negotiation, the rogue server sends an initial protocol frame that declares mysql_clear_password as the initial authentication plugin.

Upon receiving this frame, the vulnerable client constructs a HandshakeResponse and immediately writes the plaintext database password to the TCP socket. The rogue server receives and extracts this password. Once the password is captured, the rogue server terminates the connection, completing the credential theft.

The security impact of this flaw is classified as a complete confidentiality compromise of database credentials. Because database passwords frequently grant administrative access to backend database resources, an attacker who obtains this password can compromise database confidentiality, integrity, and availability.

The CVSS v3.1 score is evaluated at 5.9 (Medium), reflecting the high complexity required to execute the attack. The adversary must possess active network positioning to conduct a Man-in-the-Middle attack or redirect the application network configuration to a rogue endpoint.

While the vulnerability exposes critical credentials, it does not directly enable remote code execution or data modification on the client system itself. Its primary threat is as an access vector to downstream database infrastructure. There is currently no evidence of active exploitation in the wild.

The primary remediation for this vulnerability is upgrading the MariaDB Connector/J library to a patched release. Maintainers have released fixes across multiple versions of the library, including stable and legacy branches.

For applications built on the 3.5.x branch, upgrade to 3.5.9 or later. For applications built on 3.4.x, upgrade to 3.4.3. Applications on 3.3.x require 3.3.5, while 2.7.x deployments require upgrading to 2.7.14.

To mitigate the risk of credential leakage without immediately upgrading, administrators must eliminate trust fallback states. This is achieved by explicitly defining trusted certificates. Applications should set the serverSslCert parameter in their JDBC URL to point to a specific trusted certificate, or supply a dedicated Java TrustStore via trustStore and trustStorePassword parameters, disabling the insecure system fallback logic.