MariaDB Connector/J CVE-2026-55856

Exploitation requires all four of the following conditions to hold simultaneously: (1) the Java application uses MariaDB Connector/J with sslMode=verify-full or sslMode=verify-ca; (2) a database password is provided in the connection configuration; (3) neither serverSslCert nor trustStore is configured, causing the connector to use the default ephemeral trust manager with fallbackToSystemTrustStore=true; and (4) the attacker holds an active man-in-the-middle position on the TCP/TLS network path between the client and the MariaDB server. Exploitation is limited by the high complexity of acquiring a network MITM position and by the fact that only the initial-handshake path is affected - established connections are not exposed retroactively. From the attacker's side, no privileges are required (CVSS PR:N). Applications that pin the server certificate via serverSslCert or trustStore, applications that do not supply a password, and applications not using mysql_clear_password as the initial server-advertised plugin are not vulnerable even on unpatched versions.

The CVSS 3.1 score of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) accurately reflects the core tension in this vulnerability: the confidentiality impact is maximal - the attacker receives the full plaintext database password - but the attack complexity is high, requiring the attacker to hold an active network MITM position before exploitation is possible. The High confidentiality impact is unambiguous; with captured credentials the attacker can authenticate directly to the database and access or modify all data that account is authorized for. I:N and A:N are correct for the base score because the vulnerability itself only leaks the credential; downstream damage is a post-exploitation concern. EPSS data was not provided in the intelligence input and cannot be assessed. Active exploitation is not confirmed - this CVE is absent from the CISA KEV catalog and no public exploit code is identified at time of analysis. Despite the AC:H rating, real-world risk is meaningfully elevated by the fact that this vulnerability targets users who explicitly configured TLS verification, the configuration documented by the vendor as the easy secure default, meaning these users have every reasonable expectation of being protected and are unlikely to apply compensating controls. Any environment where network interception is feasible - cloud multi-tenant segments, shared hosting, or misconfigured VPCs - narrows the practical gap between AC:H on paper and realistic exploitation. No conflicting signals exist in the available data; the CVSS vector is fully consistent with the described MITM scenario.

An attacker with a network MITM position between the Java application and its MariaDB server - achieved via ARP poisoning, a compromised network device, or a hostile cloud co-tenant - intercepts the outbound TCP connection, completes a TLS handshake using a self-signed certificate, and includes mysql_clear_password as the advertised initial authentication plugin in the spoofed server handshake packet. The vulnerable Connector/J, operating under sslMode=verify-full without a pinned certificate, transmits the application's database password in cleartext in its HandshakeResponse before performing the fingerprint identity check; the attacker captures the credential and the connection is subsequently torn down. No public exploit code is identified at time of analysis, but the HackerOne report at https://hackerone.com/reports/3777370 and the GHSA advisory document the attack in sufficient technical detail to be reproducible by a skilled attacker.