MariaDB Connector/J CVE-2026-55857

Exploitation requires all three of the following conditions to hold simultaneously. First, the MariaDB server must be configured to use PAM authentication for the target account - this is a non-default server-side configuration requiring explicit setup of the 'dialog' authentication plugin on the MariaDB server. Second, the connector must operate with sslMode=DISABLE (which IS the default connector configuration) or with a TLS mode that relies solely on self-signed certificate fingerprint validation rather than CA-verified TLS; connections using properly verified TLS (sslMode=verify-full or verify-ca) are immune. Third, an attacker must achieve an on-path network position (MITM via ARP/DNS spoofing, rogue WiFi, compromised network device) or cause the client to connect to a server they control (rogue server). Exploitation is blocked by: verified TLS on the connector (any sslMode other than DISABLE and fingerprint-only), Unix domain socket connections, setting restrictedAuth to exclude 'dialog', or the absence of PAM authentication on the server. The MITM requirement (AC:H in CVSS) is the most significant real-world limiting factor for widespread exploitation.

The NVD CVSS 3.1 score of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) correctly captures the central tension: the confidentiality impact is high (full plaintext credential capture) but attack complexity is high because the attacker must occupy an on-path MITM position or control a server the client connects to. No EPSS data was supplied in the intelligence feed and the vulnerability is absent from CISA KEV, so exploitation probability cannot be quantified numerically. No public exploit code has been identified. The practical risk is bounded by three converging requirements: PAM authentication must be configured server-side (non-default), the connector must operate with sslMode=DISABLE (the default, but not universal), and the attacker must achieve network-layer interposition. Deployments using verified TLS or Unix sockets are fully immune even without patching. The vulnerability is therefore a real priority for organizations using PAM-authenticated MariaDB over unencrypted networks - particularly containerized or cloud-native environments where TLS is sometimes intentionally disabled on internal links - but carries limited risk for deployments already enforcing TLS, which is common in security-conscious environments.

An attacker performing ARP spoofing or DNS poisoning positions themselves between a Java application server and its MariaDB backend, intercepting the TCP connection. When the application initiates a database connection, the attacker forwards traffic normally until the authentication phase, then injects an Authentication Switch Request nominating the 'dialog' plugin. The unpatched connector, lacking a secure-transport gate on the PAM handler, responds with the account password in cleartext; the attacker captures it and subsequently authenticates directly to the real MariaDB server. No public exploit code has been identified, but the attack requires only standard MITM tooling and knowledge of the MySQL wire protocol.