CVE-2026-66909

Kod walidacji MAC OAuth2 Hawk i JOSE w Apache CXF przed wersją 3.0.13 oraz 3.1.x przed wersją 3.1.10 nie używa algorytmu porównywania podpisów MAC w stałym czasie, co może być wykorzystane przez zaawansowane ataki czasowe.

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.

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.

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.

W Apache CXF w komponencie DefaultEncryptingCodeDataProvider kod autoryzacyjny może być wykorzystany wielokrotnie z powodu błędu w implementacji funkcji removeCodeGrant. Narusza to wymóg RFC, że kod autoryzacyjny nie może być użyty więcej niż raz. Zalecane jest uaktualnienie do wersji 4.2.3, 4.1.8 lub 3.6.12.

Walidacja tokenów OIDC w Apache CXF może akceptować samowystawione tokeny ID bez wymaganych kontroli roszczeń (issuer/subject/audience/time i sub_jwk binding), co umożliwia obejście uwierzytelnienia przy użyciu spreparowanych tokenów. Należy jednak zauważyć, że samowystawione tokeny ID nie są domyślnie akceptowane w walidatorze. Zalecane jest uaktualnienie do wersji 4.2.3, 4.1.8 lub 3.6.12.

W Apache CXF filtr JwtRequestCodeFilter kopiuje wszystkie roszczenia z podpisanego JWT do mapy parametrów autoryzacji bez wykluczania parametrów wrażliwych dla bezpieczeństwa. Klient, który może wygenerować prawidłowo podpisany JWT (np. gdy zna lub skompromituje client_secret), może podmienić wartości code_challenge, code_challenge_method, nonce i state, co osłabia integralność PKCE i ochronę przed replay w OpenID Connect. Zalecane jest uaktualnienie do wersji 4.2.3, 4.1.8 lub 3.6.12.

W Apache CXF w punkcie końcowym rejestracji klientów OAuth2 Dynamic Client Registration serwer autoryzacyjny akceptuje i przechowuje wartość `scope` dostarczoną w żądaniu rejestracji bez jej walidacji względem listy dozwolonych zakresów. Może to prowadzić do samodzielnego nadania sobie uprzywilejowanych zakresów przez klienta podczas rejestracji. Zalecane jest uaktualnienie do wersji 4.2.3, 4.1.8 lub 3.6.12.

Błąd logiczny w OAuthRequestFilter odrzuca prawidłowe żądania pochodzące z powiązanego adresu IP, jednocześnie bezwarunkowo przepuszczając żądania z dowolnego innego adresu IP. Włączenie tej funkcji bezpieczeństwa przypadkowo tworzy odwróconą kontrolę bezpieczeństwa.

Klasa JwtAccessTokenValidator w Apache CXF nie weryfikuje roszczeń 'aud' (Audience) w przychodzących tokenach JWT. Umożliwia to ponowne użycie tokenu JWT wydanego dla jednego serwera zasobów przeciwko innemu serwerowi, prowadząc do ataków typu Token Confusion/Routing.