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, PAM dialog authentication can be coerced into transmitting the account password over an insecure connection. The mysql_clear_password plugin is gated behind a secure transport, but the sibling PAM handler SendPamAuthPacketFactory, named dialog by the server, does not declare that requirement and inherits the default secure-required value false; older branches implement the same affected behavior in SendPamAuthPacket. A hostile or man-in-the-middle server can send an Authentication Switch Request for dialog over plain TCP, causing the driver to return the user's password in cleartext when sslMode=DISABLE and restrictedAuth=null, which is the default configuration. Properly verified TLS and local Unix sockets are not exposed to this transport vector. 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.680Z",
  "pubdate": "2026-08-28T23:17:08.680Z",
  "executiveSummary": "This vulnerability involves an insecure credential transmission flaw within the MariaDB Connector/J authentication process. The issue arises because the PAM (Pluggable Authentication Module) dialog handler fails to enforce secure transport requirements, unlike other authentication plugins.\nBy leveraging a Man-in-the-Middle (MitM) position, a malicious server can coerce the connector into transmitting the user's account password in cleartext. This occurs when the connector is configured with insecure defaults (sslMode=DISABLE and restrictedAuth=null).\nThe vulnerability affects multiple branches of the MariaDB Connector/J driver. Successful exploitation allows an attacker to intercept valid database credentials, leading to unauthorized access to the database environment. Because the flaw relies on a protocol-level bypass of secure transport requirements, it presents a significant risk to applications using default configurations over plain TCP connections.\nImpacted versions include those prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Mitigation requires upgrading the connector to the patched versions or enforcing robust TLS configurations.",
  "technicalDetails": "The vulnerability originates in the PAM dialog authentication implementation within MariaDB Connector/J. Specifically, the SendPamAuthPacketFactory (and the legacy SendPamAuthPacket) class, responsible for handling the 'dialog' authentication mechanism, fails to explicitly enforce the requirement for a secure transport layer.\nIn the MariaDB/MySQL protocol, certain authentication plugins, such as 'mysql_clear_password', are designed to verify the presence of a secure transport (TLS/SSL) before executing. However, the PAM handler inherits a default secure-required value of 'false', permitting it to operate over plain, unencrypted TCP connections.\nThe attack flow follows these steps: 1) A client establishes a connection to a database server using plain TCP (sslMode=DISABLE). 2) A hostile or MitM server triggers an 'Authentication Switch Request' during the handshake, specifically requesting the 'dialog' plugin. 3) Because the driver does not validate the secure-transport state for this specific handler, it proceeds with the authentication process.\nAs the driver satisfies the server's request, it transmits the user's password in cleartext to the remote endpoint. Since the 'restrictedAuth' parameter is null by default, the driver lacks the configuration to reject this insecure switch. This bypasses security expectations, as users assume that password transmission is protected by the protocol's security requirements.\nThe vulnerability is persistent across older branches of the driver. It is not triggered if the application enforces strict TLS validation or connects via local Unix sockets, as these methods inherently provide the transport security necessary to prevent plain-text leakage.\nThe technical root cause is the lack of a mandatory SSL-check flag in the dialog authentication factory. An attacker requires a position to intercept or simulate the database server response, allowing them to force the switch to the vulnerable PAM authentication path. Once the password is captured in cleartext, the attacker gains full authentication material, allowing for persistent unauthorized access to the database account, potentially resulting in data exfiltration, modification, or destruction."
}