CVE-2026-55856: 
Java vulnerability analysis and mitigation

CVE-2026-55856 is a cleartext password disclosure vulnerability in MariaDB Connector/J (mariadb-java-client) that allows an active man-in-the-middle attacker to capture a Java application's database password in cleartext during the initial TLS handshake. The flaw affects versions prior to 2.7.14, 3.0.0–3.3.4, 3.4.0–3.4.2, and 3.5.0–3.5.8 of the org.mariadb.jdbc:mariadb-java-client Maven package. It was published on August 28, 2026, and patched in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9. The vulnerability carries a CVSS v3.1 base score of 5.9 (Medium) (GitHub Advisory).

The root cause is a combination of CWE-522 (Insufficiently Protected Credentials) and CWE-295 (Improper Certificate Validation). When sslMode=verify-full or sslMode=verify-ca is configured with a password but without a pinned serverSslCert or trustStore, Connector/J uses an ephemeral trust manager (fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint for later identity binding. The critical flaw is that the certificate fingerprint enforcement guard — which prevents sending credentials over an unverified connection — was applied to the OK-packet and auth-switch paths but was absent from the initial-handshake path. Specifically, HandshakeResponse.encode() would build and transmit a mysql_clear_password response before checking certFingerprint != null && !isMitMProof(), sslMode, or restrictedAuth, allowing a rogue server to receive the full cleartext password before the connection is torn down (GitHub Advisory, Fix Commit).

An active man-in-the-middle or hostile server positioned on the network path can present a self-signed certificate, claim to be a MariaDB server, and select mysql_clear_password as the initial authentication plugin, receiving the victim's full database password in cleartext before the connection is rejected. This defeats the TLS verification protection the developer explicitly configured, as the credential is exfiltrated before any identity check runs. With the captured credentials, an attacker can authenticate to the real database server and read or modify all data the compromised account is authorized to access, potentially enabling lateral movement within the infrastructure (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation as of the time of publication (GitHub Advisory). The NVD SSVC assessment classifies exploitation as "none" and the attack as non-automatable, reflecting the requirement for an active network position (man-in-the-middle or hostile server). The EPSS score is approximately 0.0022 (0.22%), indicating a low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. No threat actor attribution has been reported.

1. Position on the network path: The attacker must be in a man-in-the-middle position between the Java application and the database server, or operate a rogue server that the application connects to (e.g., via DNS spoofing, ARP poisoning, or a misconfigured connection string).
2. Present a self-signed TLS certificate: The rogue server presents any non-expired self-signed TLS certificate during the TLS handshake. Because the victim application has no pinned serverSslCert or trustStore, Connector/J's ephemeral trust manager accepts the certificate and records its fingerprint.
3. Advertise mysql_clear_password as the initial authentication plugin: In the initial handshake packet (protocol 10), the rogue server sets the auth-plugin-name field to mysql_clear_password and advertises SSL capability.
4. Receive cleartext password: The vulnerable Connector/J driver, without checking the certificate fingerprint or MITM-proof status on the initial-handshake path, builds and sends a HandshakeResponse containing the database password in cleartext over the TLS channel to the rogue server.
5. Drop the connection: The rogue server records the captured password and drops the connection. The Java application receives a connection error, while the attacker now possesses valid database credentials (GitHub Advisory, Fix Commit).

• Network: Unexpected TLS connections to database endpoints terminating with a self-signed certificate not matching the expected CA or server certificate; short-lived database connection attempts that result in immediate disconnection after the handshake phase.
• Logs: Java application logs showing SQLException or connection errors immediately after TLS handshake with messages referencing authentication plugin failures or certificate issues; repeated failed connection attempts to the database from the application host.
• Application Behavior: Unexpected database authentication failures from legitimate application instances, potentially indicating that captured credentials are being used concurrently from an attacker-controlled host.
• Network Traffic: Database protocol traffic (default port 3306) where the server's initial handshake packet specifies mysql_clear_password as the authentication plugin, which is atypical for standard MariaDB/MySQL deployments.

Upgrade org.mariadb.jdbc:mariadb-java-client to a patched version: 2.7.14 (for 2.x branch), 3.3.5 (for 3.0–3.3.x), 3.4.3 (for 3.4.x), or 3.5.9 (for 3.5.x). The fix applies the certFingerprint != null && !isMitMProof() guard to the initial-handshake path before sending the authentication response, matching the behavior already present on the OK-packet and auth-switch paths (GitHub Advisory, 3.4.3 Release, 3.5.9 Release). If an immediate upgrade is not possible, pin the server certificate using the serverSslCert connection parameter pointing to the real CA or server certificate; this causes a MITM's self-signed certificate to be rejected at the TLS layer before any authentication exchange occurs. Additionally, using local Unix domain sockets exclusively for database connections eliminates the network attack surface entirely.

HeroDevs published a blog post covering CVE-2026-55856 alongside related MariaDB Connector/J CVEs in the context of Spring Boot applications, highlighting the risk to Java application stacks (HeroDevs Blog). The vulnerability was reported via HackerOne (report #3777370) and tracked in MariaDB's JIRA as CONJ-1325. Red Hat opened a Bugzilla entry (bug #2525813) to track the impact on their distributions (Red Hat Bugzilla). Tenable released Nessus plugin 342406 to detect vulnerable versions.