CVE-2026-119278

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

MariaDB Connector/J w wersjach od 3.0.0 do 3.3.7, 3.4.5 i 3.5.11 używał w metodzie ClientMessage.validateLocalFileName() wyrażenia regularnego, które mogło dopasować tekst LOAD DATA LOCAL INFILE wewnątrz cytowanych identyfikatorów, literałów ciągów lub komentarzy, zamiast wymagać rzeczywistej instrukcji. Złośliwy lub przejęty serwer albo atakujący typu man-in-the-middle mógł zwrócić spreparowane identyfikatory bazy danych lub tabeli, które łącznik wykorzystał w zapytaniach metadanych lub aktualizowalnych wyników, a następnie odpowiedzieć żądaniem LOCAL INFILE dla pliku klienta. Przy włączonym allowLocalInfile powodowało to przesyłanie przez łącznik dowolnego czytelnego pliku hosta klienta wskazanego przez spreparowany tekst, w tym przez ścieżki DatabaseMetaData.getImportedKeys(), DatabaseMetaData.getExportedKeys() lub ResultSet.updateRow(). 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.