Listen to this Post
When a Java application connects with `sslMode=verify-full` (or verify-ca) and a password but does not pin a server certificate, Connector/J deliberately accepts an untrusted or self-signed certificate at the TLS layer. This is part of the “MITM-proof without a CA” feature, where the connector proves the server’s identity afterwards by binding the certificate fingerprint into the authentication exchange.
The fingerprint enforcement is applied to the OK-packet and auth-switch paths. However, it is absent on the initial-handshake path. In HandshakeResponse.encode(), the connector builds the `mysql_clear_password` response after checking only that SSL is enabled. It never consults the recorded fingerprint, sslMode, or whether the plugin is MITM-proof.
By this point, the connector already knows the certificate is self-signed. The `mysql_clear_password` plugin does not declare itself MITM-proof (it inherits the safe default), confirming it is meant to be refused on an unverified certificate. The initial-handshake path simply never consults that flag and also bypasses restrictedAuth.
An active man-in-the-middle can present a self-signed certificate, claim to be MariaDB, and name `mysql_clear_password` as the initial authentication plugin. The victim’s database password is then received in cleartext before any fingerprint or identity check runs. The connection is torn down a moment later, but the credential is already exfiltrated.
The vulnerability affects Java applications using Connector/J with `sslMode=verify-full` or verify-ca, a password, and no pinned certificate — a configuration documented as the easy, secure default. An attacker who captures these credentials can take over the database account and read or modify all data that account is authorized for. The victim takes no unusual action; the developer explicitly enabled TLS verification expecting exactly this protection.
The issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9. The fix applies the same `certFingerprint != null && !isMitMProof()` guard to the initial-handshake path before writing the auth response, refusing to send a `mysql_clear_password` (or any non-MITM-proof) response on an unverified certificate. If you cannot upgrade immediately, pin the server certificate (serverSslCert=) — with a pinned certificate, the self-signed certificate of a man-in-the-middle is rejected at the TLS layer before any password is transmitted.
DailyCVE Form:
Platform: ……. MariaDB Connector/J
Version: …….. 2.x < 2.7.14, 3.x < 3.3.5/3.4.3/3.5.9
Vulnerability :…… Cleartext password disclosure
Severity: ……. Medium (CVSS 5.9)
date: ………. 2026-08-28
Prediction: …… Patch available (2026-06-15)
What Undercode Say:
Analytics – Verify Vulnerable Configuration:
Check Connector/J version in your project Maven mvn dependency:tree | grep mariadb-java-client Gradle gradle dependencies | grep mariadb-java-client Direct JAR check jar -tf mariadb-java-client-.jar | grep -i version
Analytics – Test MITM Exposure (Educational):
Simulate a malicious server (Educational Purposes Only!) Using openssl to create a self-signed certificate openssl req -x509 -newkey rsa:2048 -keyout mitm-key.pem -out mitm-cert.pem -days 1 -nodes -subj "/CN=malicious-mariadb-server" Start a rogue server that advertises mysql_clear_password This is a conceptual demonstration - actual exploitation requires a custom server echo "Rogue server would request mysql_clear_password and capture credentials"
Analytics – Code-Level Check (Vulnerable Path):
// VULNERABLE CODE PATH (before patch)
// HandshakeResponse.encode() checks only SSL enabled
if (this.sslEnabled) {
// Builds mysql_clear_password response
// Does NOT check certFingerprint or isMitMProof()
// Password sent in cleartext before identity verification
}
Exploit: (Educational Purposes!)
An active MITM attacker positions themselves between the Java application and the legitimate MariaDB server. The attacker:
1. Presents a self-signed certificate to the client during TLS handshake.
2. Claims to be a MariaDB server.
3. Selects `mysql_clear_password` as the initial authentication plugin.
- Receives the full database password in cleartext via `HandshakeResponse.encode()` before any fingerprint check occurs.
- The connection is later rejected, but the credential is already captured.
Conceptual Proof-of-Concept (Educational):
MITM setup using socat (conceptual - not a working exploit) Attacker intercepts traffic between client and legitimate server socat -v -x OPENSSL-LISTEN:3306,cert=mitm-cert.pem,key=mitm-key.pem,verify=0 \ OPENSSL-CONNECT:legitimate-server:3306,verify=0 The attacker can now observe the mysql_clear_password packet containing the cleartext password
Protection:
1. Immediate Upgrade: Update to patched versions:
- 2.x → 2.7.14 or later
- 3.0/3.1/3.2/3.3.x → 3.3.5 or later
- 3.4.x → 3.4.3 or later
- 3.5.x → 3.5.9 or later
- Workaround (if upgrade not possible): Pin the server certificate using `serverSslCert` parameter pointing to the real CA or server certificate. With a pinned certificate, the self-signed certificate of a man-in-the-middle is rejected at the TLS layer before any password is transmitted.
- Verify Configuration: Ensure `fallbackToSystemTrustStore` is not implicitly allowing untrusted certificates in sensitive environments.
Impact:
- Confidentiality: Full database credentials (cleartext password) are exposed to an active MITM attacker.
- Authorization: With captured credentials, the attacker can assume the victim’s database identity and perform any operation the account is authorized for (read, modify, delete data).
- User Perception: The victim application executes normally; the developer explicitly enabled TLS verification (
sslMode=verify-full) expecting protection, yet the vulnerability silently exposes credentials. - Scope: All Java applications using MariaDB Connector/J with `sslMode=verify-full` or
verify-ca, a password, and no pinned certificate are affected. - CVSS Score: 5.9 (Medium)
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
