Apache Tomcat: fala błędów autoryzacji, HTTP/2 i WebSocket naprawiona w trzech gałęziach

Apache ujawnił szeroki pakiet poprawek bezpieczeństwa dla Tomcat, który trafił do 11.0.25, 10.1.58 i 9.0.121. Najważniejsze problemy nie tworzą jednego uniwersalnego RCE. Dotykają za to miejsc, którym aplikacje Java powierzają decyzje o dostępie: dopasowania security-constraint, Realm, FORM i DIGEST authentication, reguł RewriteValve, ścisłej walidacji SNI, sesji WebSocket i obsługi zasobów HTTP/2.

W polskiej strefie rekordy zostały zaindeksowane w nocnym cyklu 26 sierpnia, a strona projektu wskazuje publiczne ujawnienie 25 sierpnia. Dla administratora ważniejszy od różnicy dat jest wspólny próg naprawy: wspierane gałęzie powinny zostać podniesione co najmniej do wersji wymienionych wyżej. Stare 8.5 i 7.0 są w wielu przypadkach również podatne, lecz pozostają poza wsparciem i nie dostały równoważnego bieżącego wydania.

Dlaczego ten pakiet jest istotny mimo różnych ocen

Apache oznaczył część błędów jako Important, część jako Moderate lub Low. Nie należy sumować ocen ani zakładać, że każdy serwer jest podatny na każdy scenariusz. Wiele ścieżek wymaga konkretnej konfiguracji: DataSourceRealm, CLIENT-CERT lub SPNEGO, RewriteValve z flagą [N], DIGEST authentication, Unix Domain Socket albo aplikacja utrzymująca uwierzytelnione WebSockety.

Jednocześnie Tomcat jest warstwą egzekwującą politykę dla tysięcy aplikacji. Błąd o niskiej złożoności w mapowaniu roli może mieć wysoki skutek biznesowy, jeśli chroniony endpoint zmienia płatności, dane klienta lub konfigurację. Ocena ryzyka musi więc połączyć severity producenta z osiągalnością w konkretnym server.xml, context.xml, web.xml, kodzie aplikacji i topologii proxy.

CVE-2026-65182: kolejność constraintów zmieniała wynik

Apache sklasyfikował CVE-2026-65182 jako Important. Podatne przetwarzanie pozwalało ominąć bardziej restrykcyjny constraint dla krótszej podścieżki, jeżeli wcześniej zdefiniowano constraint dla dłuższej ścieżki. Narusza to podstawową intuicję administratora: efektywna polityka powinna wynikać z semantyki dopasowania, a nie z przypadkowej kolejności deklaracji.

Affected ranges obejmują Tomcat 11.0.0-M1–11.0.24, 10.1.0-M1–10.1.57 i 9.0.0.M1–9.0.120. Rekord wymienia również EOL 8.5.0–8.5.100 oraz 7.0.0–7.0.109. Poprawka znajduje się w 11.0.25, 10.1.58 i 9.0.121.

Przegląd powinien objąć nakładające się wzorce URL, role, http-method i http-method-omission. Nie wystarczy wygenerować pojedynczego żądania do jednej ścieżki. Macierz testów musi zawierać ścieżkę bazową, dłuższy prefiks, warianty końcowego ukośnika, wszystkie metody i role negatywne. Test regresyjny powinien przechodzić przez ten sam connector i proxy co ruch produkcyjny.

CVE-2026-68569: uwierzytelnienie mogło zakończyć się fail-open

Drugi problem oznaczony Important dotyczy przypadków takich jak CLIENT-CERT i SPNEGO współpracujących z DataSourceRealm. CVE-2026-68569 powodowało, że użytkownik mógł zostać uznany za uwierzytelnionego mimo braku jego rekordu w Realm. To istotne rozróżnienie: zewnętrzny mechanizm może poprawnie potwierdzić certyfikat lub ticket, ale aplikacja nadal oczekuje, że lokalny katalog zmapuje principal na aktywne konto i role.

Zakres wspieranych gałęzi to 11.0.0-M1–11.0.24, 10.1.0-M1–10.1.57 i 9.0.0.M1–9.0.120. Apache wskazuje także podatne, niewspierane linie 8.5 i 7.0. Organizacje używające certyfikatów klienta lub Kerberos powinny testować nie tylko prawidłowego użytkownika, ale również poprawne poświadczenie z nazwą nieobecną, wyłączoną albo inaczej znormalizowaną w źródle danych.

W logach warto korelować sukces z warstwy protokołu z wynikiem zapytania Realm. Zdarzenie „certyfikat poprawny” nie jest równoznaczne z „konto istnieje i ma prawo wejścia”. Telemetria powinna pokazać principal, źródło tożsamości, wynik lookupu i przypisane role bez zapisywania sekretów ani pełnych biletów.

CVE-2026-65927 i CVE-2026-65637: granica routingu i hosta

CVE-2026-65927, również Important, jest błędem off-by-one w RewriteValve. Flaga [N] miała rozpocząć przetwarzanie reguł od nowa, lecz restart następował od drugiej reguły. Jeśli pierwsza reguła pełniła rolę ochronną — normalizowała ścieżkę, blokowała wzorzec albo kierowała ruch przez kontrolę — kolejne przejście mogło ją ominąć.

To nie oznacza, że każda instalacja z RewriteValve była dostępna bez autoryzacji. Potrzebny jest układ reguł, w którym wielokrotne przetwarzanie i pominięcie pierwszej instrukcji zmienia decyzję bezpieczeństwa. Administrator powinien zinwentaryzować [N], ustawić limit iteracji, a następnie przetestować wejścia wymagające co najmniej dwóch przebiegów. Do czasu aktualizacji można uprościć reguły tak, aby mechanizm bezpieczeństwa nie zależał wyłącznie od pierwszego kroku.

CVE-2026-65637 ma ocenę Moderate i jest niepełną poprawką CVE-2026-32990. Żądanie HTTP/2 bez :authority mogło ominąć strict SNI validation. Dotyczy węższego zakresu: 11.0.20–11.0.24, 10.1.53–10.1.57 i 9.0.115–9.0.120. Przypadek pokazuje, że kontrola spójności TLS SNI i hosta HTTP musi bezpiecznie obsłużyć brak wartości, a nie tylko różnicę tekstową.

CVE-2026-68763: reset streamu i wyciek alokacji

W CVE-2026-68763 napastnik mógł manipulować resetowaniem strumieni HTTP/2, aby wywołać wyciek alokacji w śledzeniu backlogu i doprowadzić do denial of service. Apache oznaczył problem jako Important. Podatne są 11.0.0-M1–11.0.24, 10.1.0-M1–10.1.57 i 9.0.39–9.0.120, a także niewspierana gałąź 8.5 od 8.5.59.

Warstwa proxy może ograniczyć część ekspozycji, jeśli kończy HTTP/2 i przekazuje do Tomcat HTTP/1.1, ale nie wolno tego zakładać bez sprawdzenia rzeczywistej ścieżki. W środowiskach z pass-through, h2c albo bezpośrednim connectorem podatny kod nadal przetwarza strumienie. Monitoruj pamięć procesu, liczbę resetów, aktywne strumienie, kolejkę i częstotliwość restartów. Sam limit liczby połączeń może nie zatrzymać wielu resetów w jednym połączeniu.

Mniejsze błędy, które nadal mogą naruszyć granicę

Pakiet obejmuje również CVE-2026-68525: po FORM authentication przekierowanie mogło ominąć constraint ograniczający POST, ale nie GET. CVE-2026-66422 dotyczyło nieprawidłowego użycia security-role-ref jako aliasów w Realm poza ich właściwym znaczeniem dla Request.isUserInRole(). CVE-2026-65905 pozwalało na jednokrotne odtworzenie określonego żądania DIGEST w oknie nonceCount.

CVE-2026-65183 opisuje lokalny wyścig TOCTOU przy tworzeniu Unix Domain Socket, który mógł umożliwić nieuprawnionemu lokalnemu użytkownikowi dostęp do gniazda. CVE-2026-73180 pozostawiało uwierzytelnione połączenie WebSocket po zakończeniu powiązanej sesji HTTP, gdy identyfikator sesji zmienił się po zestawieniu połączenia.

Te błędy mają niższe oceny, ale testują ważne inwarianty: metoda HTTP pozostaje częścią decyzji; alias roli nie rozszerza Realm; ochrona replay jest monotoniczna; prawa do socketu obowiązują od chwili utworzenia; długie połączenie kończy się razem z utratą sesji. Organizacje nie powinny rozdzielać aktualizacji na „ważne CVE” i „resztę”, skoro jedna wersja naprawcza obejmuje cały pakiet.

Jak bezpiecznie wdrożyć aktualizację

Najpierw ustal skuteczną wersję każdego procesu. Obraz aplikacji może zawierać Tomcat, framework może dołączać embedded Tomcat, a platforma PaaS może wstrzykiwać własny runtime. Sprawdź SBOM, lockfile, warstwy obrazu i log startowy. Dla Spring Boot liczy się rozwiązywana wersja tomcat-embed-*, nie wyłącznie wersja startera.

Następnie aktualizuj do 11.0.25, 10.1.58 lub 9.0.121 albo nowszego wspieranego patcha w tej samej gałęzi. Tomcat 8.5 i 7.0 należy migrować do wspieranej linii, a nie czekać na patch, którego projekt nie obiecuje. Nie kopiuj pojedynczych JAR-ów między instalacjami: zestaw bibliotek i plików startowych powinien pozostać spójny z dystrybucją.

W środowisku przedprodukcyjnym wykonaj testy autoryzacji pozytywnej i negatywnej, handshake CLIENT-CERT/SPNEGO, reguły rewrite, FORM/DIGEST, utratę sesji WebSocket oraz obciążenie HTTP/2. Sprawdź też różnice konfiguracyjne i flagi JVM. Po canary porównaj odsetek 401/403, błędy Realm, resetowane streamy, zużycie pamięci i nieoczekiwane zamknięcia WebSocketów.

Priorytetyzacja oparta na konfiguracji

Najwyższy priorytet mają internetowe serwery z deklaratywnymi constraintami, RewriteValve lub bezpośrednim HTTP/2, a także systemy używające CLIENT-CERT/SPNEGO z DataSourceRealm. Następnie sprawdź aplikacje z długimi, uwierzytelnionymi WebSocketami oraz współdzielone hosty, gdzie lokalny użytkownik może rywalizować o zasoby Unix socket.

Brak jednej funkcji nie jest powodem do pozostania na starej wersji. Pakiet ujawnia kilka niezależnych błędów, a inwentaryzacja konfiguracji bywa niepełna. Jeżeli zgodność aplikacji blokuje patch, ogranicz publiczny dostęp, zakończ HTTP/2 przed Tomcat, usuń zależność security od RewriteValve i dodaj kontrolę autoryzacji w aplikacji — ale traktuj te zmiany jako czasowe.

Fakty źródłowe i wnioski Breachroad

Nazwy CVE, opisy mechanizmów, poziomy severity, daty publicznego ujawnienia, zakresy wersji i docelowe wydania pochodzą ze stron bezpieczeństwa Apache Tomcat oraz rekordów CVE. Źródła nie informują o potwierdzonej aktywnej eksploatacji omawianego pakietu. Macierz testów, priorytety konfiguracyjne, monitoring i zalecenia canary są wnioskami Breachroad.

Szkolenia secure coding i bezpieczeństwa infrastruktury pomagają zespołom zrozumieć granice autoryzacji, sesji i protokołów, a testy aplikacji i API mogą zweryfikować efektywne polityki Tomcat w rzeczywistym wdrożeniu.