CVE-2026-119210

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 zakładał, że bajty wyników są w UTF-8, ale kontrolował tylko zmiany character_set_client. Nie odrzucał zmian character_set_results na inne niż UTF-8 i polegał na globalnej konfiguracji session_track_system_variables serwera do raportowania zmian zestawu znaków. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wyłączyć śledzenie lub zmienić zestaw znaków wyników, przez co ciągi znaków w aplikacji różniły się od zwróconych bajtów, potencjalnie obchodząc walidację lub escapowanie po stronie aplikacji zależne od zdekodowanych wartości. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 ma implementacje MariaDbPoolConnection.recover() i MariaDbPoolPinnedConnection.recover(), które ufają kolumnom gtrid_length i bqual_length zwracanym przez XA RECOVER. Metody te alokują i dzielą tablice bajtów Xid bez walidacji długości względem Xid.MAXGTRIDSIZE, Xid.MAXBQUALSIZE lub rzeczywistego ładunku danych. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle może spowodować duże alokacje, NegativeArraySizeException lub ArrayIndexOutOfBoundsException podczas odzyskiwania XA. Problem naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.10 zawiera błąd w metodach ReadableByteBuf.readLength() i ReadableByteBuf.readIntLengthEncodedNotNull(), które zawężały 8-bajtową liczbę całkowitą bez znaku (length-encoded integer) do Java int bez sprawdzenia, czy wartość mieści się w zakresie nieujemnej liczby całkowitej. Wartości powyżej Integer.MAX_VALUE mogły zawinąć się do ujemnej lub niepowiązanej długości używanej przez dalsze ścieżki alokacji i odczytu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wywołać NegativeArraySizeException, błędy out-of-bounds lub nadmierną alokację w obsłudze połączenia klienta. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.10.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7 i 3.4.5 podczas uwierzytelniania caching_sha2_password traktował odpowiedź authentication-more-data jako tablicę bajtów z kodowaniem długości, alokował pamięć na podstawie długości zadeklarowanej przez serwer i uzyskiwał dostęp do authResult[0] bez zapewnienia istnienia bajtu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł zadeklarować bardzo dużą długość lub wysłać pustą odpowiedź przed przesłaniem hasła. Zniekształcony pakiet mógł spowodować nadmierną alokację lub niekontrolowany ArrayIndexOutOfBoundsException wydostający się z DriverManager.getConnection(). Naprawiono w wersjach 3.3.7 i 3.4.5.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 dekodery bloków stanu sesji pakietu OK, pakietów definicji kolumn, danych wierszy tekstowych lub binarnych używały długości zadeklarowanych przez serwer bez potwierdzenia, że żądane bajty pozostają w buforze odbioru. Dekodery mogły pozycjonować odczyty, tworzyć podbufory lub dekodować ciągi poza granicą pakietu. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wywołać niekontrolowane wyjątki ArrayIndexOutOfBoundsException lub IllegalArgumentException w wywołaniach JDBC i przerwać obsługę połączenia. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11, gdy wynegocjowano CLIENT_SESSION_TRACK, ścieżki OkPacket.parse() i OkPacket.parseWithInfo() alokowały tablice bajtów na podstawie długości zadeklarowanych przez serwer dla pola info pakietu OK oraz nazw i wartości zmiennych stanu sesji, zanim potwierdzono, że bajty pozostają w pakiecie. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł wysłać mały pakiet OK deklarujący znacznie większą długość i wielokrotnie wymuszać alokacje sterty kontrolowane przez atakującego, zanim kolejna kopia zakończyła się niepowodzeniem. Mogło to powodować presję na garbage collector lub OutOfMemoryError w aplikacji klienckiej. Naprawiono w wersjach 3.3.7, 3.4.5 i 3.5.11.

Konektor MariaDB Connector/J w wersjach przed 2.7.14, 3.3.5, 3.4.3 i 3.5.9 nie wymusza opcji allowLocalInfile=false podczas przetwarzania pakietu LOCAL INFILE. Złośliwy lub man-in-the-middle serwer może spowodować przesłanie pliku wybranego przez aplikację, mimo wyłączonej opcji. Luka została naprawiona w wersjach 2.7.14, 3.3.5, 3.4.3 i 3.5.9.

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.

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

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.