Podatności Apache Tomcat

Podatność w Apache Tomcat związana z niewłaściwym zamykaniem lub zwalnianiem zasobów umożliwia atak typu 'made you reset'. Dotyczy to wersji od 11.0.0-M1 do 11.0.9, od 10.1.0-M1 do 10.1.43 oraz od 9.0.0.M1 do 9.0.107.

Implementacja HTTP/2 w Apache Tomcat od wersji 9.0.0.M1 do 9.0.0.M21 oraz od 8.5.0 do 8.5.15 omijała szereg zabezpieczeń, które zapobiegały atakom typu directory traversal. Możliwe było obejście ograniczeń bezpieczeństwa przy użyciu specjalnie skonstruowanego URL.

Parser nagłówków HTTP/2 w Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M11 oraz od 8.5.0 do 8.5.6 wchodził w nieskończoną pętlę, gdy otrzymał nagłówek większy niż dostępny bufor. To umożliwiało przeprowadzenie ataku typu denial of service.

W Apache Tomcat w wersjach od 9.0.0.M1 do 9.0.0.M18 oraz od 8.5.0 do 8.5.12, obsługa ramki GOAWAY w protokole HTTP/2 nie zamykała strumieni związanych z połączeniem, które czekały na WINDOW_UPDATE, co mogło prowadzić do wyczerpania dostępnych wątków przetwarzania.

Kod w Apache Tomcat w wersjach od 6.0.0 do 9.0.0.M11 pozwalał na parsowanie linii żądania HTTP z nieprawidłowymi znakami. Może to być wykorzystane w połączeniu z proxy, które również akceptuje te znaki, do wstrzykiwania danych do odpowiedzi HTTP.

Odkryto błąd programistyczny w przetwarzaniu żądań HTTPS w silniku serwletów i JSP Apache Tomcat, który może prowadzić do odmowy usługi z powodu nieskończonej pętli. Problem ten wynika z niepoprawnego przeniesienia poprawki CVE-2016-6816 bez uwzględnienia poprawki dla błędu Tomcat 57544.

Podatność polegająca na niedoczytaniu bufora w Apache Tomcat powoduje, że duży zapis nieblokujący może spowodować podział treści odpowiedzi między bieżące żądanie a następne żądanie odebrane na tym samym połączeniu, co najprawdopodobniej prowadzi do błędu drugiego żądania i możliwego wycieku danych z pierwszej odpowiedzi do drugiej.

Nieprawidłowe recykling i ponowne użycie obiektów w Apache Tomcat wpływa na przetwarzanie asynchronicznych servletów HTTP/2 i może powodować mieszanie żądań i/lub odpowiedzi między użytkownikami. Dotyczy wersji 11.0.22 do 11.0.26, 10.1.55 do 10.1.60 oraz 9.0.118 do 9.0.122.

Brak krytycznego kroku uwierzytelniania w Apache Tomcat, gdy realm JNDI był skonfigurowany z mechanizmem SASL innym niż GSSAPI, pozwalał atakującym na uwierzytelnienie bez podania prawidłowego hasła. Dotyczy wersji 11.0.0-M1 do 11.0.26, 10.1.0-M1 do 10.1.60 oraz 9.0.0.M1 do 9.0.122; znane są również wersje EOL 8.5.0-8.5.100 i 7.0.0-7.0.109.

Podatność polegająca na niespójnej interpretacji żądań HTTP/2 (przemyt żądań HTTP) w Apache Tomcat, spowodowana regresją w poprawce dla CVE-2026-41293, może prowadzić do pomieszania nagłówków żądań. Problem dotyczy Apache Tomcat od 11.0.22 do 11.0.25, od 10.1.55 do 10.1.59 oraz od 9.0.118 do 9.0.121. Zaleca się aktualizację do wersji 11.0.26, 10.1.60 lub 9.0.122.

Podatność w Apache Tomcat, gdzie uwierzytelnianie CLIENT_CERT nie zawodzi zgodnie z oczekiwaniami w niektórych scenariuszach, gdy wyłączony jest tryb miękkiego błędu. Problem dotyczy Apache Tomcat od 11.0.0-M14 do 11.0.25, od 10.1.22 do 10.1.59 oraz od 9.0.92 do 9.0.121. Zaleca się aktualizację do wersji 11.0.26, 10.1.60 lub 9.0.122.

Podatność w Apache Tomcat umożliwia obejście zabezpieczeń dla dowolnego punktu końcowego WebSocket poprzez użycie alternatywnej nazwy. Dotyczy to wersji od 11.0.0-M1 do 11.0.25, od 10.1.0-M1 do 10.1.59 oraz od 9.0.0.M1 do 9.0.121. Zalecane jest uaktualnienie do wersji 11.0.26, 10.1.60 lub 9.0.122.

Nieprawidłowa autoryzacja w procesie uwierzytelniania FORM w Apache Tomcat pozwala na ominięcie ograniczenia bezpieczeństwa, które ogranicza użytkownikowi dostęp do zasobu dla metody POST, ale nie dla GET.

Obejście uwierzytelniania przez przechwycenie i powtórzenie w mechanizmie DIGEST w Apache Tomcat. Jeśli przed wykonaniem windowSize żądań klient wykona żądanie uwierzytelnione DIGEST z nonceCount na górnej granicy okna powtórzeń, to żądanie może być powtórzone tylko raz, dopóki nonceCount pozostaje w oknie.

Podatność na nieprawidłową walidację danych wejściowych w Apache Tomcat, wynikająca z niekompletnej poprawki dla CVE-2026-32990. Dotyczy wersji 11.0.20-11.0.24, 10.1.53-10.1.57 oraz 9.0.115-9.0.120.

Podatność dotycząca nieprawidłowej kontroli dostępu i autoryzacji w Apache Tomcat, prowadząca do obejścia ograniczeń bezpieczeństwa, jeśli ograniczenie dla dłuższej ścieżki jest zdefiniowane przed bardziej restrykcyjnym ograniczeniem dla krótszej pod-ścieżki. Dotyczy szerokiego zakresu wersji od 7.0.0 do 11.0.24.

W Apache Tomcat wykryto podatność związaną z niewystarczającą dokumentacją techniczną, która nie opisywała jasno wymagań bezpiecznej konfiguracji EncryptInterceptor. Problem dotyczy wielu wersji Tomcat od 7.0.100 do 11.0.23.

Podatność w mechanizmie przepisywania adresów URL (rewrite valve) Apache Tomcat umożliwia ominięcie ograniczeń bezpieczeństwa poprzez nieprawidłowe kodowanie szesnastkowe. Problem dotyczy wielu wersji Tomcat, w tym 11.0.0-M1 do 11.0.23, 10.1.0-M1 do 10.1.56, 9.0.0-M1 do 9.0.119 oraz 8.5.0 do 8.5.100.

Podatność w Apache Tomcat powoduje, że specjalne role i puste ograniczenia autoryzacji nie są uwzględniane podczas logowania efektywnego pliku web.xml. Problem dotyczy wersji od 11.0.0-M1 do 11.0.22, od 10.1.0-M1 do 10.1.55, od 9.0.0.M1 do 9.0.118 oraz od 8.5.0 do 8.5.100.

W Apache Tomcat wykryto podatność polegającą na braku reakcji na błąd podczas konfigurowania list CRL dla konektora opartego na FFM. Problem dotyczy wersji od 11.0.0-M1 do 11.0.22, od 10.1.0-M7 do 10.1.55 oraz od 9.0.83 do 9.0.118.

W przykładowej aplikacji do zgadywania liczb w Apache Tomcat wykryto podatność na podstawowy atak XSS (Cross-Site Scripting). Brak odpowiedniej neutralizacji znaczników HTML związanych ze skryptami umożliwia atakującemu wstrzyknięcie złośliwego kodu JavaScript.

Podatność w mechanizmie uwierzytelniania typu digest w Apache Tomcat umożliwia obejście uwierzytelnienia. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, 10.1.0-M1 do 10.1.54, 9.0.0.M1 do 9.0.117, 8.5.0 do 8.5.100 oraz wersji przed 7.0.0.

Podatność związana z niewłaściwą walidacją danych wejściowych w Apache Tomcat może prowadzić do nieautoryzowanego dostępu lub manipulacji danymi. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, od 10.1.0-M1 do 10.1.54, od 9.0.0.M1 do 9.0.117 oraz od 10.0.0-M1 do 10.0.27.

Podatność typu Padding Oracle w domyślnej konfiguracji EncryptInterceptor w Apache Tomcat. Umożliwia atakującemu odszyfrowanie danych przesyłanych przez szyfrowany kanał.

Apache Tomcat nie escapował sekwencji ANSI w komunikatach logów. Gdy Tomcat działał w konsoli systemu Windows obsługującej sekwencje ANSI, atakujący mógł za pomocą specjalnie spreparowanego URL wstrzyknąć sekwencje ANSI, manipulować konsolą i schowkiem oraz nakłonić administratora do uruchomienia polecenia kontrolowanego przez atakującego.

Podatność typu Relative Path Traversal w Apache Tomcat. Poprawka dla błędu 60013 wprowadziła regresję, w której przepisany URL był normalizowany przed dekodowaniem, co umożliwia atakującemu manipulację URI żądania w celu ominięcia zabezpieczeń, w tym ochrony katalogów /WEB-INF/ i /META-INF/. Jeśli włączone są żądania PUT, możliwe jest przesłanie złośliwych plików prowadzące do zdalnego wykonania kodu.

Podatność typu 'Open Redirect' w funkcji uwierzytelniania FORM w Apache Tomcat umożliwia przekierowanie użytkowników na niezaufane strony. Dotyczy to wersji Apache Tomcat od 11.0.0-M1 do 11.0.0-M10, od 10.1.0-M1 do 10.0.12, od 9.0.0-M1 do 9.0.79 oraz od 8.5.0 do 8.5.92.

W Apache Tomcat 10.1.0-M1 do 10.1.0-M16, 10.0.0-M1 do 10.0.22, 9.0.30 do 9.0.64 oraz 8.5.50 do 8.5.81 przykład uwierzytelniania formularza w przykładowej aplikacji webowej wyświetlał dane dostarczone przez użytkownika bez filtrowania, co narażało na podatność XSS.

Jeśli aplikacja internetowa wysyła komunikat WebSocket jednocześnie z zamykaniem połączenia WebSocket podczas działania na Apache Tomcat 8.5.0 do 8.5.75 lub Apache Tomcat 9.0.0.M1 do 9.0.20, możliwe jest, że aplikacja będzie nadal używać gniazda po jego zamknięciu. Obsługa błędów wyzwolona w tym przypadku może spowodować umieszczenie obiektu z puli w puli dwukrotnie. Może to skutkować tym, że kolejne połączenia będą używać tego samego obiektu jednocześnie, co może prowadzić do zwrócenia danych niewłaściwemu użytkownikowi i/lub innych błędów.

Dokumentacja Apache Tomcat w wersjach 10.1.0-M1 do 10.1.0-M14, 10.0.0-M1 do 10.0.20, 9.0.13 do 9.0.62 i 8.5.38 do 8.5.78 dla EncryptInterceptor błędnie stwierdzała, że umożliwia on działanie klastra Tomcat w niezaufanej sieci. W rzeczywistości EncryptInterceptor zapewnia ochronę poufności i integralności, ale nie chroni przed wszystkimi zagrożeniami związanymi z działaniem w niezaufanej sieci, szczególnie przed atakami DoS.

Apache Tomcat 8.5.0 do 8.5.63, 9.0.0-M1 do 9.0.43 oraz 10.0.0-M1 do 10.0.2 nieprawidłowo walidowały przychodzące pakiety TLS. Gdy Tomcat był skonfigurowany do używania NIO+OpenSSL lub NIO2+OpenSSL dla TLS, specjalnie spreparowany pakiet mógł wywołać nieskończoną pętlę prowadzącą do odmowy usługi.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.6, 9.0.0.M1 do 9.0.46 i 8.5.0 do 8.5.66 niepoprawnie parsował nagłówek transfer-encoding w niektórych sytuacjach, co umożliwia przemycanie żądań (request smuggling) w połączeniu z odwrotnym proxy. Tomcat ignorował nagłówek transfer-encoding, gdy klient deklarował akceptację tylko odpowiedzi HTTP/1.0, honorował kodowanie identity i nie zapewniał, że chunked encoding jest ostatnim kodowaniem.

Podatność w JNDI Realm Apache Tomcat umożliwia atakującemu uwierzytelnienie przy użyciu odmian poprawnej nazwy użytkownika oraz/lub ominięcie części ochrony zapewnianej przez LockOut Realm. Problem dotyczy Apache Tomcat 10.0.0-M1 do 10.0.5, 9.0.0.M1 do 9.0.45 oraz 8.5.0 do 8.5.65.

Poprawka dla CVE-2020-9484 była niekompletna. Podczas korzystania z Apache Tomcat 10.0.0-M1 do 10.0.0, 9.0.0.M1 do 9.0.41, 8.5.0 do 8.5.61 lub 7.0.0 do 7.0.107 z konfiguracją, która była bardzo mało prawdopodobna do użycia, instancja Tomcat była nadal podatna na CVE-2020-9494. Należy zauważyć, że zarówno wcześniej opublikowane wymagania wstępne dla CVE-2020-9484, jak i wcześniej opublikowane środki łagodzące dla CVE-2020-9484 mają również zastosowanie do tego problemu.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0, 9.0.0.M1 do 9.0.41 oraz 8.5.0 do 8.5.61, podczas odpowiadania na nowe żądania połączeń h2c, może duplikować nagłówki żądań i ograniczoną ilość treści żądania z jednego żądania do drugiego, co oznacza, że użytkownik A i użytkownik B mogą widzieć wyniki żądania użytkownika A.

Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M9, 9.0.0.M1 do 9.0.39, 8.5.0 do 8.5.59 i 7.0.0 do 7.0.106 jest podatny na ujawnienie kodu źródłowego JSP w niektórych konfiguracjach, gdy serwuje zasoby z lokalizacji sieciowej na systemie plików NTFS. Przyczyną jest nieoczekiwane zachowanie metody File.getCanonicalPath() w JRE, spowodowane niespójnym zachowaniem API Windows (FindFirstFileW).

Podczas badania błędu 64830 odkryto, że Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M9, 9.0.0-M1 do 9.0.39 oraz 8.5.0 do 8.5.59 może ponownie użyć wartości nagłówka żądania HTTP z poprzedniego strumienia odebranego na połączeniu HTTP/2 dla żądania związanego z kolejnym strumieniem. Choć najprawdopodobniej prowadzi to do błędu i zamknięcia połączenia HTTP/2, możliwe jest wyciekanie informacji między żądaniami.

Jeśli klient HTTP/2 łączący się z Apache Tomcat przekroczy uzgodnioną maksymalną liczbę równoczesnych strumieni dla połączenia (z naruszeniem protokołu HTTP/2), możliwe jest, że kolejne żądanie na tym połączeniu będzie zawierać nagłówki HTTP - w tym pseudo-nagłówki HTTP/2 - z poprzedniego żądania zamiast zamierzonych. Może to prowadzić do sytuacji, w której użytkownicy zobaczą odpowiedzi dla nieoczekiwanych zasobów.

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M6, 9.0.0.M1 do 9.0.36, 8.5.0 do 8.5.56 i 7.0.27 do 7.0.104 długość ładunku w ramce WebSocket nie była poprawnie walidowana. Nieprawidłowe długości ładunku mogły wywołać nieskończoną pętlę, a wiele takich żądań mogło prowadzić do odmowy usługi.

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M6, 9.0.0.M5 do 9.0.36 i 8.5.1 do 8.5.56, bezpośrednie połączenie h2c nie zwalniało procesora HTTP/1.1 po przejściu na HTTP/2. Wystarczająca liczba takich żądań mogła spowodować OutOfMemoryException, prowadząc do odmowy usługi.

Specjalnie spreparowana sekwencja żądań HTTP/2 wysłana do Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M5, 9.0.0.M1 do 9.0.35 oraz 8.5.0 do 8.5.55 może wywołać wysokie użycie CPU przez kilka sekund. Jeśli wykonano wystarczającą liczbę takich żądań na równoczesnych połączeniach HTTP/2, serwer może stać się nieosiągalny.

W Apache Tomcat w wersjach 10.0.0-M1 do 10.0.0-M4, 9.0.0.M1 do 9.0.34, 8.5.0 do 8.5.54 i 7.0.0 do 7.0.103, jeśli atakujący może kontrolować zawartość i nazwę pliku na serwerze, a serwer jest skonfigurowany z PersistenceManager z FileStore i odpowiednimi filtrami, możliwe jest zdalne wykonanie kodu poprzez deserializację pliku.

W Apache Tomcat 9.0.0.M1 do 9.0.30, 8.5.0 do 8.5.50 oraz 7.0.0 do 7.0.99 kod parsowania nagłówków HTTP używał podejścia do analizy końca linii, które pozwalało na parsowanie niektórych nieprawidłowych nagłówków HTTP jako poprawnych. To prowadziło do możliwości przemycania żądań HTTP (HTTP Request Smuggling), jeśli Tomcat znajdował się za odwrotnym proxy, które nieprawidłowo obsługiwało nieprawidłowy nagłówek Transfer-Encoding w szczególny sposób. Takie odwrotne proxy jest uważane za mało prawdopodobne.

Apache Tomcat w wersjach 9.0.28 do 9.0.30, 8.5.48 do 8.5.50 i 7.0.98 do 7.0.99 zawiera regresję, która powoduje nieprawidłowe przetwarzanie nieprawidłowych nagłówków Transfer-Encoding, co może umożliwić przemycanie żądań HTTP (request smuggling) w przypadku, gdy Tomcat znajduje się za odwrotnym proxy, które nieprawidłowo obsługuje te nagłówki.

W Apache Tomcat w wersjach 9.0.0.M1 do 9.0.29, 8.5.0 do 8.5.49 oraz 7.0.0 do 7.0.98, przy użyciu autoryzacji FORM, istnieje wąskie okno czasowe, w którym atakujący może przeprowadzić atak polegający na fiksacji sesji. Okno to uznano za zbyt wąskie, aby exploit był praktyczny, ale z ostrożności potraktowano to jako podatność.

Poprawka dla CVE-2019-0199 była niekompletna i nie rozwiązywała wyczerpania okna połączenia HTTP/2 podczas zapisu w Apache Tomcat 9.0.0.M1 do 9.0.19 i 8.5.0 do 8.5.40.

Polecenie SSI printenv w Apache Tomcat w wersjach 9.0.0.M1 do 9.0.0.17, 8.5.0 do 8.5.39 oraz 7.0.0 do 7.0.93 zwraca dane dostarczone przez użytkownika bez escapowania, co czyni je podatnym na XSS. SSI jest domyślnie wyłączone, a polecenie printenv jest przeznaczone do debugowania i prawdopodobnie nie występuje w witrynach produkcyjnych.