Most recent entries from all

BIT-mariadb-2026-55215 — MariaDB Connector/Node.js: Connector leaks the cleartext password to an MitM despite `ssl: true`

Affected: Bitnami: mariadb

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 mysql_clear_password 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 mysql_clear_password 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.

fkie_cve-2026-55215

GHSA-cqhc-2h57-wpxf — MariaDB's connector leaks the cleartext password to an MitM despite `ssl: true`

Affected: npm: mariadb

### 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. VERIFY_CA / VERIFY_FULL).

Reported by haaahaaahiihiiii (no GitHub account).