CVE-2026-55856
ŚrednieCVSS 5.9Streszczenie
MariaDB Connector/J przed wersjami 2.7.14, 3.3.5, 3.4.3 i 3.5.9, gdy aplikacja Java łączy się z sslMode=verify-full lub verify-ca, podaje hasło i nie konfiguruje serverSslCert lub trustStore, może zaakceptować niezaufany certyfikat self-signed przez tymczasowy menedżer zaufania fallbackToSystemTrustStore=true i zapisać jego certFingerprint do późniejszego wiązania tożsamości. Ścieżki OK-packet i authentication-switch egzekwują odcisk certyfikatu, ale ścieżka initial-handshake nie. HandshakeResponse.encode() może zbudować i wysłać odpowiedź mysql_clear_password przed sprawdzeniem certFingerprint, sslMode lub odporności na man-in-the-middle, a ścieżka początkowa również omija restrictedAuth. Aktywny man-in-the-middle lub wrogi serwer może przedstawić certyfikat self-signed, podać się za MariaDB, wybrać mysql_clear_password jako początkowy plugin uwierzytelniania i otrzymać pełne hasło bazy danych przed odrzuceniem połączenia.
Ocena ryzyka
Ryzyko przechwycenia haseł użytkowników, co może prowadzić do nieautoryzowanego dostępu do bazy danych i naruszenia poufności danych.
Rekomendacja
Zaleca się aktualizację do wersji 2.7.14, 3.3.5, 3.4.3 lub 3.5.9, które zawierają poprawkę, oraz skonfigurowanie zaufanych certyfikatów serwera.
Inne podatności w MariaDB Connector/J
Zobacz wszystkie- CVE-2026-55858Średnie
MariaDB Connector/J przed wersjami 2.7.14, 3.3.5, 3.4.3 i 3.5.9 koduje i dekoduje tekst protokołu oraz wykonuje escapowanie po stronie klienta przy założeniu, że zestaw znaków połączenia to UTF-8. Serwer może zgłosić zmianę character_set_client w trakcie sesji przez OK-packet session-state tracking, w tym przez SET NAMES, procedurę składowaną lub wyzwalacz, konfigurację serwera lub wrogi serwer. Jeśli character_set_client zmieni się na nie-UTF-8, sterownik kontynuuje odczyt i zapis UTF-8, podczas gdy serwer interpretuje te same bajty w innym kodowaniu, powodując cichą korupcję danych i niezgodność zestawów znaków, co może obejść cytowanie lub escapowanie bajtowe.
- CVE-2026-55857Średnie
MariaDB Connector/J przed wersjami 2.7.14, 3.3.5, 3.4.3 i 3.5.9 może być zmuszony do przesłania hasła konta przez niezabezpieczone połączenie podczas uwierzytelniania PAM dialog. Plugin mysql_clear_password jest chroniony wymogiem bezpiecznego transportu, ale handler PAM SendPamAuthPacketFactory (nazwany dialog przez serwer) nie deklaruje tego wymogu i dziedziczy domyślną wartość secure-required false. Wrogi lub man-in-the-middle serwer może wysłać Authentication Switch Request dla dialog przez zwykłe TCP, powodując, że sterownik zwróci hasło użytkownika w postaci jawnego tekstu, gdy sslMode=DISABLE i restrictedAuth=null (domyślna konfiguracja).
Oryginalny opis (angielski, źródło NVD)
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.