GHSA-qxvw-fvwx-5cp7

### 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 mysql_clear_password 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 mysql_clear_password: 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](https://github.com/fg0x0/)).