Podatności Apache CXF

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.

Transport JMS w Apache CXF deserializuje treść każdej przychodzącej wiadomości JMS ObjectMessage przy użyciu natywnej deserializacji Java, bez żadnych ograniczeń typów. Każdy atakujący, który może umieścić wiadomość w kolejce JMS usługi, może przesłać złośliwy zserializowany obiekt, prowadząc do odmowy usługi lub, jeśli odpowiednia klasa gadget znajduje się na ścieżce klas, do zdalnego wykonania kodu. Poprawka wyłącza domyślnie deserializację ObjectMessage, z możliwością ponownego włączenia przez konfigurację.

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.

Klasy EndpointReferenceUtils i W3CMultiSchemaFactory w Apache CXF tworzą SAXParserFactory bez niezbędnych zabezpieczeń JAXP, co umożliwia rozwiązywanie zewnętrznych encji poza pasmem (OOB).

Podatność na wstrzykiwanie LDAP w repozytorium certyfikatów LDAP serwera XKMS w Apache CXF. Umożliwia atakującemu pobranie dowolnych certyfikatów z repozytorium.

Polityka UsernameToken w Apache CXF w wersjach 2.4.5 i 2.5.1 pozwala zdalnym atakującym na ominięcie uwierzytelniania poprzez wysłanie pustego UsernameToken w żądaniu SOAP.

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.

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.

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.

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.

Ten identyfikator CVE został odrzucony lub wycofany przez organizację numerującą CVE. Jest duplikatem CVE-2026-1829.

W Apache CXF w DefaultEncryptingOAuthDataProvider odwołane tokeny dostępu nadal poprawnie deszyfrują się, a TokenIntrospectionService raportuje active:true. To samo dotyczy tokenów odświeżania. Narusza to wymagania RFC, które mówią, że 'serwer autoryzujący MUSI unieważnić token' oraz 'introspekcja odwołanego tokena MUSI zwrócić {"active":false}'. Zaleca się aktualizację do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem.

Wyścig w JCacheCodeDataProvider pozwala atakującemu na wielokrotne wykorzystanie pojedynczego kodu autoryzacyjnego poprzez równoczesne żądania, co skutkuje wydaniem wielu różnych, ważnych tokenów dostępu. Zaleca się aktualizację do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem.

Apache CXF odczytuje najwyższego poziomu WSDL przez zahartowaną ścieżkę StaxUtils, która wyłącza DTD i zewnętrzne encje XML. Jednakże każde <wsdl:import> lub <xsd:import> odwołujące się z tego WSDL jest przekazywane do WSDL4J, które nie wyłącza deklaracji DOCTYPE ani zewnętrznych encji. W rezultacie ochrona zastosowana do dokumentu najwyższego poziomu nie obejmuje zaimportowanych dokumentów, pozostawiając zaimportowaną treść WSDL/XSD podatną na ataki XML External Entity (XXE).

Niekompletna poprawka dla CVE-2026-50645 oznacza, że nadal możliwe jest przeprowadzenie ataku typu denial of service na Apache CXF poprzez wysłanie wiadomości z wieloma nagłówkami załączników. Zaleca się aktualizację do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem.

Apache CXF pozwala ustawić limit liczby parametrów formularza w wiadomości JAX-RS za pomocą opcji konfiguracyjnej "maxFormParameterCount". Jednak nie jest ustawiony żaden domyślny limit, co może prowadzić do ataków typu denial of service podczas przetwarzania żądań z bardzo dużą liczbą parametrów formularza. Zaleca się aktualizację do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem, ustawiając domyślny limit 500 parametrów.

Specyfikacja OpenID Connect Core 1.0 wymaga, aby RP (Relying Party) walidowało parametr `c_hash` podczas działania w trybie Hybrydowym. Jeśli RP Apache CXF jest zintegrowane z niezgodnym lub źle skonfigurowanym dostawcą tożsamości (IdP), który pomija `c_hash`, RP staje się podatne na ataki typu Authorization Code Substitution/Injection. Zaleca się aktualizację do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem.

Apache CXF pozwala kontrolować maksymalny rozmiar załącznika za pomocą opcji "attachment-max-size". Przed wersjami 4.2.3, 4.1.8 i 3.6.12 nie było domyślnego limitu tego rozmiaru, co oznacza, że atak typu denial of service jest możliwy, jeśli użytkownik nie ustawi limitu jawnie. Użytkownicy powinni zaktualizować Apache CXF do wersji 4.2.3, 4.1.8 lub 3.6.12, które naprawiają ten problem, narzucając domyślny limit rozmiaru załącznika wynoszący 50 MB.

Brak ograniczenia liczby nagłówków załączników w Apache CXF podczas deserializacji wiadomości może prowadzić do niekontrolowanego zużycia zasobów lub ataku DoS. Zalecana jest aktualizacja do wersji 4.2.2, 4.1.7 lub 3.6.12, które wprowadzają domyślny limit 500 załączników na wiadomość.

Podatność w JwsJsonContainerRequestFilter w Apache CXF może być wykorzystana do przetwarzania metadanych, które nie zostały uwierzytelnione przez akceptowany podpis. Może to ominąć założenie aplikacji, że akceptowane nagłówki Content-Type lub chronione nagłówki HTTP pochodzą z zweryfikowanego wpisu podpisu, i może wpłynąć na dalsze parsowanie encji JAX-RS lub sprawdzanie spójności podpisanych nagłówków. Zalecana aktualizacja do wersji 4.2.2, 4.1.7 lub 3.6.12.

W module integracji JCA w Apache CXF wykryto podatność na wstrzyknięcie JNDI, która może umożliwić wykonanie kodu, jeśli atakujący jest w stanie manipulować deskryptorem wdrożenia JCA (ra.xml) lub parametrami aktywacji.

W Apache CXF zidentyfikowano niepełną poprawkę dla wcześniejszej porady CVE-2026-44417 (niezaufana konfiguracja JMS może prowadzić do RCE), która nadal może umożliwić wykonanie kodu, jeśli nieufni użytkownicy mogą konfigurować JMS dla Apache CXF.

W AbstractOAuthDataProvider występuje wyścig, który pozwala równoczesnym żądaniom z tym samym tokenem odświeżania na ominięcie zasady jednorazowego użycia i wygenerowanie wielu ważnych tokenów dostępu, gdy 'recycleRefreshTokens' jest ustawione na false. Zalecana jest aktualizacja do wersji 4.2.2, 4.1.7 lub 3.6.12.

Podatność obejścia uwierzytelniania w usłudze OAuth2 TokenIntrospectionService w Apache CXF. Z powodu brakującego słowa kluczowego 'throw' w sprawdzeniu kontekstu bezpieczeństwa, punkt końcowy (/services/oauth2/introspect) może być dostępny dla każdego nieuwierzytelnionego atakującego sieciowego. Należy jednak zauważyć, że jest to zabezpieczenie tylko w przypadku, gdy ktoś zapomniał włączyć uwierzytelnianie na usłudze. Zalecana aktualizacja do wersji 4.2.2, 4.1.7 lub 3.6.12.

Podatność XXE w module WS-Transfer w Apache CXF z powodu niebezpiecznej konfiguracji parsera XML. Atakujący może wstrzyknąć złośliwe encje XML.

Poprawka dla CVE-2025-48913 w Apache CXF była niekompletna, co oznacza, że inna ścieżka w kodzie może umożliwić wykonanie kodu, jeśli niezaufani użytkownicy mogą konfigurować JMS dla Apache CXF. Zaleca się aktualizację do wersji 4.2.1, 4.1.6 lub 3.6.11.