Description

MariaDB Connector/Node.js is used to connect applications developed on Node.js to MariaDB and MySQL databases. Prior to 3.2.4, 3.3.3, 3.4.6, and 3.5.3, MariaDB Connector/Node.js can disclose an account password when PAM dialog authentication is negotiated over an insecure transport. In lib/cmd/handshake/auth/pam-password-auth.js and lib/cmd/handshake/authentication.js, the SendPamAuthPacketFactory behavior for the server-side plugin dialog lacked the secure-transport gate applied to mysql_clear_password. With the default sslMode=DISABLE and restrictedAuth=null settings, a hostile or on-path server can send an Authentication Switch Request for dialog over plain TCP, causing the connector to return the account password in cleartext. Properly verified TLS and a local Unix socket prevent this path, while fingerprint-only server identity validation is not sufficient. This issue is fixed in versions 3.2.4, 3.3.3, 3.4.6, and 3.5.3.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-08-28T23:17:08.203Z",
  "pubdate": "2026-08-28T23:17:08.203Z",
  "executiveSummary": "This vulnerability is an information disclosure flaw within the MariaDB Connector/Node.js, specifically concerning PAM dialog authentication.\nThe issue arises from a failure to enforce secure transport requirements during the authentication negotiation process, allowing an attacker to intercept cleartext credentials.\nAffected versions include MariaDB Connector/Node.js prior to 3.2.4, 3.3.3, 3.4.6, and 3.5.3.\nThe vulnerability poses a critical risk of credential theft, enabling unauthorized database access if an attacker acts as a malicious or on-path server.\nExploitation is possible when the connector is configured with default settings (sslMode=DISABLE and restrictedAuth=null), allowing a rogue server to force a downgrade or bypass the lack of encryption during authentication.\nSuccessful exploitation requires the attacker to position themselves as a man-in-the-middle or host a malicious MariaDB instance, triggering an Authentication Switch Request over an insecure channel to capture credentials.",
  "technicalDetails": "The vulnerability resides in the authentication handshake logic of the MariaDB Connector/Node.js, specifically within lib/cmd/handshake/auth/pam-password-auth.js and lib/cmd/handshake/authentication.js.\nThe root cause is the absence of a secure-transport verification gate within the SendPamAuthPacketFactory component, which handles server-side plugin dialogs.\nWhile the connector implements security checks for mysql_clear_password, this protection was inadvertently omitted for PAM dialog authentication, allowing it to function over insecure, unencrypted TCP connections.\nAttack flow: When a client connects to a database, the server can initiate an Authentication Switch Request. An attacker controlling a malicious server or acting as an on-path entity can trigger this request, specifically targeting the dialog plugin.\nBecause the connector lacks a mandatory check for TLS encryption when using PAM dialog authentication, it proceeds to transmit the user's password in cleartext to fulfill the authentication request.\nThis scenario is specifically viable when the client relies on default configurations, namely sslMode=DISABLE and restrictedAuth=null. Under these conditions, the connector does not enforce the requirement for a cryptographically secure tunnel.\nThe exploit is facilitated by the fact that the client logic prioritizes the authentication flow without validating the integrity of the underlying transport layer. Even if server identity validation via fingerprints is enabled, it is insufficient to mitigate this specific credential exposure risk.\nThe resulting impact is the complete compromise of the database account credentials utilized by the Node.js application. Once the password is captured in cleartext, the attacker can leverage these credentials to authenticate legitimately, potentially leading to unauthorized data access, modification, or lateral movement within the database environment.\nThe vulnerability is limited to network-based authentication scenarios where encryption is not strictly enforced. Communication via local Unix sockets is immune, as the underlying transport mechanism does not present the same exposure to external on-path interception."
}