CVE-2026-107937

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.

Parser zapytań FIQL w Apache CXF ma podatność w sposobie wyszukiwania operatorów w wyrażeniach zapytań. Wzorzec wyszukiwania może utknąć próbując wielu kombinacji przy długim ciągu bez operatora, powodując nadmierne zużycie CPU. Atakujący może wysłać spreparowane zapytanie, aby zużyć zasoby CPU serwera, potencjalnie spowalniając lub zatrzymując inne żądania. Poprawka ogranicza wyrażenia FIQL do 4 KiB domyślnie.

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.

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.