CVE-2026-55215: MariaDB Connector/Node.js: Connector leaks the cleartext password to an MitM despite `ssl: true`
Summary When SSL/TLS is enabled but no CA / server certificate is provided, the connector verifies the server's identity using fingerprint validation. The check is effective, the connection is ultimately rejected when it fails, but it happens after the authentication exchange. As a result, the credentials are sent before validation occurs, so an active man-in-the-middle who presents their own certificate receives the password in the handshake before the connection is aborted.
Impact The credentials are transmitted to the peer before the server's identity is validated. An on-path attacker (MitM) presenting any certificate can capture the account password, even though the connection then fails the fingerprint check and is closed. The disclosed credentials can subsequently be used to authenticate directly against the server.
- Attacker requirement: active man-in-the-middle position on the network path - Affected configuration: SSL/TLS enabled without a CA / server certificate
Affected versions - < 3.2.4 - 3.3.0 – 3.3.2 - 3.4.0 – 3.4.5 - 3.5.0 – 3.5.2
Patches Fixed in 3.2.4, 3.3.3, 3.4.6, and 3.5.3. Upgrade to one of these (or later) on your branch.
Workarounds Until you can upgrade, configure certificate verification explicitly, provide the server/CA certificate and use a verifying SSL mode (e.g. VERIFYCA / VERIFYFULL).
Reported by haaahaaahiihiiii (no GitHub account).
Other sources
MariaDB Connector/Node.js is used to connect applications developed on Node.js to MariaDB and MySQL databases. Prior to versions 3.3.3, 3.4.6, and 3.5.3, when ssl is enabled without a pinned CA or server certificate, MariaDB Connector/Node.js sends credentials before completing certificate fingerprint validation. In lib/cmd/handshake/auth/handshake.js, a server that selects mysqlclearpassword as the initial authentication plugin can receive the password before the post-TLS identity check. In lib/cmd/handshake/authentication.js, an authentication switch can evaluate the previous plugin instead of the requested target plugin, allowing mysqlclearpassword to send the credential first. An active man-in-the-middle can present a self-signed certificate, capture the database password, and use it to authenticate directly even though the connector later rejects the server and closes the connection. This issue is fixed in versions 3.3.3, 3.4.6, and 3.5.3.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.5.3 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.4.6 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.3.3 - Upgrade
Upgrade
npm/mariadbto a version that resolves this vulnerability.Fixed in 3.2.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.2.4 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.3.3 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.4.6 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.5.3 - Configuration
Until you can upgrade, configure certificate verification explicitly by using a verifying SSL mode (e.g., VERIFY_CA / VERIFY_FULL) instead of enabling SSL/TLS without a pinned CA / server certificate.
MariaDB Connector/Node.js SSL/TLS certificate verification = VERIFY_CA / VERIFY_FULL
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments using affected connector versions are exposed only when SSL/TLS is enabled without configuring a CA or server certificate. The affected versions are releases before 3.2.4, 3.3.0 through 3.3.2, 3.4.0 through 3.4.5, and 3.5.0 through 3.5.2.
What access does an attacker need to obtain credentials?
An attacker needs an active man-in-the-middle position on the network path between the connector and the server. They can present their own certificate and receive the password during authentication before fingerprint validation causes the connection to be rejected.
How should affected installations be remediated?
Upgrade to version 3.2.4, 3.3.3, 3.4.6, or 3.5.3, or a later release on the applicable branch. These versions correct the validation ordering issue.
How can I determine whether a deployment may already be affected?
Check both the installed connector version and its TLS configuration. A deployment may be affected if it runs one of the listed versions and enables SSL/TLS without a CA or server certificate.