CVE-2021-24122
ŚrednieCVSS 5.9Prawdopodobieństwo exploitacji (EPSS)
Bardzo wysokie ryzykoPercentyl 98 - wyżej niż 98% wszystkich znanych CVE
Streszczenie
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).
Ocena ryzyka
Ryzyko polega na możliwości ujawnienia wrażliwego kodu źródłowego aplikacji, co może ułatwić atakującemu znalezienie innych podatności lub obejście zabezpieczeń.
Rekomendacja
Zaleca się aktualizację Apache Tomcat do wersji zawierającej poprawkę. Należy również unikać serwowania zasobów z lokalizacji sieciowych na systemach NTFS, jeśli to możliwe.
Inne podatności w Apache Tomcat
Zobacz wszystkie- CVE-2026-43513Wysokie
Podatność związana z niewłaściwym traktowaniem wielkości liter w LockOutRealm w Apache Tomcat może prowadzić do nieautoryzowanego dostępu. 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, od 8.5.0 do 8.5.100 oraz od 7.0.0 do 7.0.109.
- CVE-2026-42498Wysokie
Podatność w Apache Tomcat związana z ujawnieniem nagłówka uwierzytelniania HTTP nieoczekiwanym hostom podczas uwierzytelniania WebSocket. Dotyczy wersji od 11.0.0-M1 do 11.0.21, 10.1.0-M1 do 10.1.54, 9.0.2 do 9.0.117, 8.5.24 do 8.5.100 oraz 7.0.83 do 7.0.109.
- CVE-2026-41284Wysokie
W Apache Tomcat występuje podatność związana z alokacją zasobów bez ograniczeń lub throttlingu. Dotyczy to wersji od 11.0.0-M1 do 11.0.21, od 10.1.0-M1 do 10.1.54 oraz od 9.0.0.M1 do 9.0.117.
- CVE-2025-48989Wysokie
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.
- CVE-2017-7675Wysokie
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.
- CVE-2016-6817Wysokie
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.
- CVE-2017-5664Wysokie
Mechanizm stron błędów w specyfikacji Java Servlet wymaga, aby oryginalne żądanie i odpowiedź były przekazywane do strony błędu. W przypadku statycznych plików, oczekiwane zachowanie to obsługa treści pliku jak w przypadku żądania GET, co nie było realizowane w Apache Tomcat w wersjach 9.0.0.M1 do 9.0.0.M20, 8.5.0 do 8.5.14, 8.0.0.RC1 do 8.0.43 oraz 7.0.0 do 7.0.77.
- CVE-2017-5650Wysokie
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.
- CVE-2017-5647Wysokie
Błąd w obsłudze żądań pipelined w Apache Tomcat powoduje utratę żądania, gdy przetwarzanie pliku send file dla poprzedniego żądania zostanie zakończone. Może to prowadzić do sytuacji, w której odpowiedzi są wysyłane dla niewłaściwych żądań.
- CVE-2016-6816Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

