CVE-2026-55857: MariaDB Connector/J: Cleartext Transmission of Sensitive Information and Insufficiently Protected Credentials
Summary
When PAM (dialog) authentication is used, the connector can be coerced into sending the account password in cleartext over an insecure connection. A hostile or man-in-the-middle server can trigger this with the default configuration, disclosing the user's password.
Details
The mysqlclearpassword plugin is gated behind a secure connection: the driver refuses to transmit the password in cleartext over plain TCP. The sibling PAM plugin handler (SendPamAuthPacketFactory, server-side plugin name dialog) did not override that gate and inherited the default value false, so it was not subject to the same secure-transport requirement.
As a result, a hostile or man-in-the-middle server can issue an Authentication Switch Request for the dialog plugin over plain TCP, and the driver responds with the user's password in cleartext. With the default configuration (sslMode=DISABLE, restrictedAuth=null) this is reachable with no non-default options.
Am I affected?
You are affected if all of the following hold:
You use mariadb Connector/J at a version below the patched release(s). Connections can occur over an insecure transport — i.e. plain TCP (sslMode=DISABLE), or a TLS mode that establishes server identity only via self-signed-certificate fingerprint validation. An attacker can occupy an on-path (MITM) position, or otherwise cause the client to connect to a server they control, and present an Authentication Switch Request for the dialog plugin.
Connections over properly verified TLS or a local Unix socket are not exposed to this vector.
Impact
Disclosure of the authenticating account's password in cleartext to an on-path or hostile server. The captured credentials can then be reused to authenticate to the database.
Patches
Fixed in 2.7.14, 3.3.5, 3.4.3, and 3.5.9. Upgrade to the patched release on your branch (3.5.x → 3.5.9, 3.4.x → 3.4.3, 3.0/3.1/3.2/3.3.x → 3.3.5, 2.x → 2.7.14). PAM (dialog) is now treated exactly like mysqlclearpassword: it may only run over a secure transport. SendPamAuthPacketFactory overrides the secure-required flag to true, and the authentication dispatcher permits a secure-required plugin only when the connection is TLS or a local Unix socket. The pre-existing check that blocks non-MITM-proof plugins when server identity relies solely on self-signed-certificate fingerprint validation continues to apply. Net effect: PAM is allowed over TLS or a Unix socket, and rejected over plain TCP or fingerprint-only connections.
Workarounds
If you cannot upgrade immediately:
Connect over verified TLS (set sslMode=verify-full) so a man-in-the-middle cannot impersonate the server, or use a local Unix socket. Restrict the permitted authentication plugins via restrictedAuth so dialog cannot be negotiated over an insecure transport.
Credit
Reported by Yalguun Tumenkhuu (@fg0x0).
Other sources
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 mysqlclearpassword 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.5.9 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.4.3 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 3.3.5 - Upgrade
Upgrade
maven/org.mariadb.jdbc:mariadb-java-clientto a version that resolves this vulnerability.Fixed in 2.7.14 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 2.7.14 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.3.5 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.4.3 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.5.9 - Configuration
When using PAM (dialog) authentication, set sslMode=verify-full so the client connects over properly verified TLS and prevents MITM from impersonating the server.
MariaDB Connector/J sslMode = verify-full - Configuration
When PAM (dialog) authentication is not required over insecure transport, restrict the permitted authentication plugins via restrictedAuth so the dialog plugin cannot be negotiated over an insecure transport (plain TCP).
MariaDB Connector/J restrictedAuth = non-dialog (restrict permitted authentication plugins) - Compensating control
Use a local Unix socket for the database connection instead of plain TCP to avoid the transport vector where a hostile server can coerce sending the dialog/PAM password in cleartext.
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Applications using affected MariaDB Connector/J versions are exposed when they connect over plain TCP with sslMode=DISABLE and restrictedAuth=null. This is the default configuration described for the affected authentication path; properly verified TLS connections and local Unix sockets are not exposed to this transport vector.
What does an attacker need to exploit it?
An attacker needs to operate a hostile server or act as a man in the middle of the database connection. They can send an Authentication Switch Request naming the dialog PAM handler, which can cause the driver to transmit the account password in cleartext.
What should be done if an immediate upgrade is not possible?
Avoid plain TCP connections using sslMode=DISABLE. Use properly verified TLS or local Unix sockets, which are not exposed to this transport vector.
Which Connector/J releases contain the fix?
The issue is fixed in MariaDB Connector/J 2.7.14, 3.3.5, 3.4.3, and 3.5.9.