Description

MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null && !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T23:17:08.513Z",
  "pubdate": "2026-08-28T23:17:08.513Z",
  "executiveSummary": "This vulnerability involves an improper authentication bypass in MariaDB Connector/J when using secure SSL modes. Specifically, the connector fails to properly validate server certificates during the initial handshake under certain configurations, allowing an attacker to perform a Man-in-the-Middle (MitM) attack.\nThe flaw affects MariaDB Connector/J versions prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9. By intercepting the connection, a hostile server or MitM attacker can trick the application into providing database credentials before the connection is formally rejected by the connector's internal security logic.\nThe vulnerability occurs when sslMode is set to 'verify-full' or 'verify-ca' without an explicitly configured serverSslCert or trustStore, causing the application to rely on the 'fallbackToSystemTrustStore' mechanism. Successful exploitation allows an attacker to capture cleartext database passwords, leading to unauthorized data access, potential privilege escalation, or complete database compromise. The exploit requires the attacker to be positioned to intercept network traffic between the Java application and the target database server.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper sequence of operations within the handshake logic of MariaDB Connector/J. When configured with 'sslMode=verify-full' or 'sslMode=verify-ca', the connector is designed to validate the authenticity of the server's TLS certificate. However, the implementation of the 'fallbackToSystemTrustStore=true' mechanism creates a race condition in the security validation flow during the initial handshake phase.\nSpecifically, when a Java application connects, the connector may accept an untrusted, self-signed certificate from a malicious entity. While the connector is intended to record the certificate's fingerprint for subsequent identity binding, the code path in 'HandshakeResponse.encode()' does not perform adequate verification of this fingerprint before proceeding with authentication.\nThe vulnerability is triggered because 'HandshakeResponse.encode()' builds and transmits a 'mysql_clear_password' response before executing the necessary security checks. These checks—which include validating 'certFingerprint', confirming the 'sslMode' parameters, and verifying the resistance of the authentication plugin against MitM attacks—are bypassed entirely during this initial phase. Furthermore, the logic fails to honor 'restrictedAuth' constraints in the initial path.\nThe attack flow proceeds as follows: 1) An attacker intercepts the initial connection attempt between the client and the legitimate database. 2) The attacker presents a fraudulent, self-signed certificate. 3) The Connector/J, failing to validate this certificate due to the faulty logic, initiates the authentication sequence. 4) The attacker forces the use of the 'mysql_clear_password' authentication plugin. 5) The client application, believing it is communicating with a trusted database, transmits the user's database password to the attacker. 6) The connector eventually rejects the connection once the verification logic catches up, but the sensitive credential has already been exfiltrated to the attacker. Because the password is sent as part of the initial handshake packet, the breach occurs before the connector can terminate the invalid session, rendering the post-connection rejection ineffective as a security control."
}