CVE-2017-5664
WysokieCVSS 7.5Prawdopodobieństwo exploitacji (EPSS)
Bardzo wysokie ryzykoPercentyl 97 - wyżej niż 97% wszystkich znanych CVE
Streszczenie
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 nie przetwarza statycznych stron błędów zgodnie z metodą GET, gdy wystąpi błąd. W zależności od oryginalnego żądania może to prowadzić do nieoczekiwanych rezultatów, w tym zastąpienia lub usunięcia niestandardowej strony błędu, jeśli DefaultServlet ma włączone zapisywanie.
Ocena ryzyka
Atakujący może wykorzystać tę podatność do modyfikacji lub usunięcia stron błędów, co może prowadzić do ujawnienia informacji lub dalszych ataków.
Rekomendacja
Zaktualizuj Apache Tomcat do wersji nowszej niż 9.0.0.M20, 8.5.14, 8.0.43 lub 7.0.77, które zawierają poprawkę.
Inne podatności w Apache Tomcat
Zobacz wszystkie- 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-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-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.
- CVE-2017-6056Wysokie
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.
- CVE-2026-103119Krytyczne
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.
- CVE-2026-101356Krytyczne
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.
- CVE-2026-101296Krytyczne
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.
- CVE-2026-86350Krytyczne
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.
Oryginalny opis (angielski, źródło NVD)
The error page mechanism of the Java Servlet Specification requires that, when an error occurs and an error page is configured for the error that occurred, the original request and response are forwarded to the error page. This means that the request is presented to the error page with the original HTTP method. If the error page is a static file, expected behaviour is to serve content of the file as if processing a GET request, regardless of the actual HTTP method. The Default Servlet in Apache Tomcat 9.0.0.M1 to 9.0.0.M20, 8.5.0 to 8.5.14, 8.0.0.RC1 to 8.0.43 and 7.0.0 to 7.0.77 did not do this. Depending on the original request this could lead to unexpected and undesirable results for static error pages including, if the DefaultServlet is configured to permit writes, the replacement or removal of the custom error page. Notes for other user provided error pages: (1) Unless explicitly coded otherwise, JSPs ignore the HTTP method. JSPs used as error pages must must ensure that they handle any error dispatch as a GET request, regardless of the actual method. (2) By default, the response generated by a Servlet does depend on the HTTP method. Custom Servlets used as error pages must ensure that they handle any error dispatch as a GET request, regardless of the actual method.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS