MariaDB Connector/J CVE-2026-55856
MEDIUM
GHSA-g9jj-cgmh-9f38
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Active network MITM required (AC:H); attacker needs no privileges (PR:N); only the database password is exposed, with no integrity or availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N
Lifecycle Timeline
2DescriptionCVE.org
MariaDB Connector/J is used to connect applications developed in Java to MariaDB and MySQL databases. Prior to 2.7.14, 3.3.5, 3.4.3, and 3.5.9, when a Java application connects with sslMode=verify-full or sslMode=verify-ca, supplies a password, and does not configure serverSslCert or trustStore, Connector/J can accept an untrusted self-signed certificate through the fallbackToSystemTrustStore=true ephemeral trust manager and record its certFingerprint for later identity binding. The OK-packet and authentication-switch paths enforce the certificate fingerprint, but the initial-handshake path does not. HandshakeResponse.encode() can therefore build and send a mysql_clear_password response before checking certFingerprint != null && !isMitMProof(), sslMode, or whether the authentication plugin is resistant to a man-in-the-middle, and the initial path also bypasses restrictedAuth. An active man-in-the-middle or hostile server can present a self-signed certificate, claim to be MariaDB, select mysql_clear_password as the initial authentication plugin, and receive the full database password before the connection is rejected. This issue is fixed in versions 2.7.14, 3.3.5, 3.4.3, and 3.5.9.
AnalysisAI
Cleartext database password disclosure in MariaDB Connector/J (all versions before 2.7.14, 3.3.5, 3.4.3, and 3.5.9) allows an active network man-in-the-middle to capture a victim application's full database password during the initial TLS handshake. The connector's initial-handshake code path transmits a mysql_clear_password authentication response before validating the certificate fingerprint that is supposed to enforce server identity - a guard that the OK-packet and auth-switch paths correctly enforce but that HandshakeResponse.encode() bypasses entirely. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | 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. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | 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. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | Full exploit scenario with step-by-step reproduction available after sign-in. |
| Remediation | Upgrade MariaDB Connector/J to one of the patched releases: 2.7.14 for the 2.x branch, 3.3.5 for the 3.3.x branch, 3.4.3 for the 3.4.x branch, or 3.5.9 for the 3.5.x branch, all available via Maven Central. … Detailed patch versions, workarounds, and compensating controls in full report. |
Threat intelligence, references, and detailed analysis are available after sign-in.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same weakness CWE-522 – Insufficiently Protected Credentials
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today