CVE-2026-86463

W Apache CXF komponent STSTokenValidator przechowywał wynik weryfikacji podpisu asercji SAML w obiekcie współdzielonym przez wszystkie żądania, umożliwiając jednemu żądaniu odczytanie wyniku innego. Zdalny, nieuwierzytelniony atakujący mógł wysłać sfałszowaną asercję podpisaną niezaufanym certyfikatem, która została zaakceptowana jako zaufana bez weryfikacji w STS. Problem dotyczy wyłącznie usług używających STSTokenValidator bez ustawienia alwaysValidateToSts.

STSTokenValidator i Security Token Service (STS) w Apache CXF buforowały zwalidowane tokeny bezpieczeństwa przy użyciu niekryptograficznego 32-bitowego skrótu (Java Arrays.hashCode/hashCode()) i traktowały trafienie w pamięć podręczną jako dowód walidacji. Atakujący mógł stworzyć token (np. UsernameToken lub samopodpisana asercja SAML) którego skrót koliduje z wpisem w pamięci podręcznej, co pozwalało na akceptację tokenu bez weryfikacji hasła, zaufania podpisu czy wywołania STS. Mogło to umożliwić atakującemu uwierzytelnienie jako inny użytkownik i uzyskanie tokenów podpisanych przez STS dla tej tożsamości.

Komponent OIDC relying-party w Apache CXF może przekierowywać użytkowników na adres URL kontrolowany przez atakującego po pomyślnym uwierzytelnieniu. Problem występuje, ponieważ parametry stanu kontrolowane przez atakującego są zachowywane i później używane jako cele przekierowania bez walidacji, że końcowy zdekodowany URI należy do origin RP. Zarówno bezpośrednio zakodowane, jak i podwójnie zakodowane zewnętrzne adresy URL mogą wywołać problem.

Metoda CompressionUtils.inflate() dekompresowała dane DEFLATE kontrolowane przez atakującego bez limitu rozmiaru wyjściowego. Mały (~KB) spreparowany ładunek mógł rozrosnąć się do gigabajtów na stercie. Było to osiągalne przez deszyfrowanie JWE gdy zip=DEF (np. JoseSessionTokenProvider z RSA-OAEP) oraz przez inflację tokenów SAML redirect/POST binding — w obu przypadkach dekompresja następuje przed lub niezależnie od walidacji zaufania. Poprawka dodaje konfigurowalny limit maksymalnego rozmiaru (domyślnie 10 MiB).

Nieprawidłowe egzekwowanie semantyki jednorazowego kodu autoryzacyjnego w dostawcy grantu OAuth2 JPA w Apache CXF pozwala zdalnemu atakującemu uzyskać wiele ważnych tokenów dostępu z jednego kodu autoryzacyjnego poprzez równoczesne żądania wymiany tokenów, które wykorzystują wyścig w nieatomowej operacji find-then-delete na współdzielonej relacyjnej bazie danych w izolacji READ_COMMITTED.

Sprawdzenie świeżości uwierzytelnienia max_age w OidcClientCodeRequestFilter było nieskuteczne z powodu niezgodności jednostek (milisekundy/sekundy) i odwróconej polaryzacji porównania. Każda relying party używająca setMaxAgeOffset do wymuszania ponownego uwierzytelnienia cicho akceptowała sesje o dowolnym wieku, omijając polityki step-up authentication.

Domyślnie StaxUtils nie nakładał limitu na całkowitą liczbę elementów ani znaków w dokumencie XML. Bardzo duże żądanie mogło zużyć dużo pamięci i CPU podczas parsowania, szczególnie gdy CXF buduje DOM z wejścia (np. SAAJ lub WS-Security), i mogło spowodować denial of service, gdy nie skonfigurowano limitu rozmiaru żądania. Obecnie oba limity mają wartości domyślne: maksymalna liczba elementów to 100 × maxChildElements (domyślnie 5 000 000), a maksymalny rozmiar dokumentu to 256M znaków.

W Apache CXF transport klienta HTTP oparty na Netty (cxf-rt-transports-http-netty-client) nie weryfikował, czy nazwa hosta w certyfikacie TLS serwera odpowiada nazwie wywoływanego hosta. Dotyczyło to zarówno HTTP/1.1, jak i HTTP/2, nawet gdy disableCNCheck pozostawało na domyślnej wartości false. Łańcuch certyfikatów był walidowany względem skonfigurowanego trust store, ale tożsamość punktu końcowego nie była. Atakujący w sieci mogący przechwycić ruch mógł przedstawić dowolny certyfikat zaufany przez klienta, np. publicznie wydany certyfikat dla kontrolowanej domeny, i podszyć się pod usługę docelową. Mógł następnie czytać lub modyfikować wymieniane wiadomości, w tym poświadczenia.

Parser nagłówków części załączników multipart/MTOM w Apache CXF nie egzekwował w pełni limitów rozmiaru i liczby nagłówków. Ograniczenie rozmiaru dotyczyło tylko pojedynczych linii, a nie wartości złożonych z linii kontynuacji ani łącznej wartości powtarzanych nagłówków. Zdalny, nieuwierzytelniony atakujący może wysłać żądanie z bardzo dużymi nagłówkami, powodując niekontrolowaną alokację pamięci i odmowę usługi.

Moduł JAX-RS XML Security w Apache CXF nie weryfikował poprawnie podpisu XML. Interceptory podpisów XML nie zapewniały, że XML przekazany do aplikacji jest objęty podpisem. Atakujący z dokumentem podpisanym przez zaufany klucz może opakować go w niepodpisane treści, które aplikacja uzna za podpisane.