Most recent entries from all

CLEANSTART-2026-MO09576 — Security fix for CVE-2026-55856 applied in: keycloak 26.5.7-r8

2026-10-04T05:45:42.038001+00:00

Affected: CleanStart: keycloak

Security vulnerability affects the keycloak package. This issue is resolved in later releases. See references for vulnerability details.

EUVD-2026-362034

2026-10-04T05:45:42.038061+00:00

EUVD-2026-362034

fkie_cve-2026-55856

2026-10-04T05:45:42.038078+00:00

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.

GHSA-g9jj-cgmh-9f38 — MariaDB has cleartext password disclosure to a MITM on the initial-handshake

2026-10-04T05:45:42.038111+00:00

Affected: Maven: org.mariadb.jdbc:mariadb-java-client

### Summary

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/self-signed certificate at the TLS layer (the "MITM-proof without a CA" feature) and proves the server's identity afterwards by binding the certificate fingerprint into the authentication exchange. That fingerprint enforcement is applied to the OK-packet and auth-switch paths but not to the initial-handshake path. An active man-in-the-middle that presents a self-signed certificate, claims to be MariaDB, and names the initial authentication plugin mysql_clear_password receives the victim's database password in cleartext, before any fingerprint/identity check runs. The connection is torn down a moment later, but the credential is already gone.

### Details

For sslMode=verify-full/verify-ca with a password and no serverSslCert/trustStore, the connector falls back to an ephemeral trust manager (default fallbackToSystemTrustStore=true) that accepts any non-expired certificate at the TLS layer and records its fingerprint. Identity is then meant to be enforced via that fingerprint.

The enforcement guard is present on two of the three paths, the OK-packet fingerprint check and the auth-switch handler (where the clear-password plugin is only allowed when the fingerprint is already verified). It is absent on the initial-handshake send: HandshakeResponse.encode() builds the mysql_clear_password respon…

WID-SEC-W-2026-3089 — MariaDB Connectors: Mehrere Schwachstellen

2026-10-04T05:45:42.038164+00:00

Ein entfernter, anonymer Angreifer kann mehrere Schwachstellen in MariaDB Connectors ausnutzen, um SQL-Injection-Angriffe durchzuführen, Sicherheitsmaßnahmen zu umgehen und Daten offenzulegen oder zu manipulieren.