CVE-2026-88920

Apache WSS4J przechowuje Nonce każdego przyjętego UsernameToken jako surowy tekst base64, ale uwierzytelnianie dekoduje ten tekst i używa bajtów. Te same bajty mogą być zapisane jako base64 na kilka sposobów. Atakujący, który przechwycił uwierzytelnione żądanie, może wysłać je ponownie z dodaną spacją do Nonce: weryfikacja hasła nadal działa, ale token nie pasuje już do zapamiętanego, więc powtórzenie jest akceptowane. Ponieważ UsernameToken nie obejmuje treści wiadomości, przechwycony token może być ponownie użyty na żądaniach wybranych przez atakującego, dopóki nie wygaśnie. Dotyczy to wdrożeń z skonfigurowanym cache replikacji Nonce, jak domyślnie w Apache CXF, i tylko tokenów używających digestu hasła. Cache jest teraz kluczowany na zdekodowanym Nonce. Zaleca się aktualizację do wersji 4.0.2, 3.0.6 lub 2.4.4, które naprawiają ten problem.

W bibliotece WSS4J występuje podatność związana z myleniem elementów potomnych EncryptedHeader, która może pozwolić atakującemu na awansowanie kontrolowanego przez niego elementu plaintext jako odszyfrowanego nagłówka. Prowadzi to do nieprawidłowego zakresu poufności i możliwego obejścia polityki bezpieczeństwa.

W walidatorze WS-SecurityPolicy strumieniowania StAX pewne względne lub nieobsługiwane wyrażenia XPath mogą być przekształcane w ścieżki, które nigdy nie pasują do rzeczywistej ścieżki elementu XML. Zdalny peer SOAP może w związku z tym wysłać wymagany element bez oczekiwanego podpisu lub szyfrowania.

Apache WSS4J akceptował kontrolowane przez atakującego długości i przesunięcia kluczy pochodnych bez odpowiednich ograniczeń. Może to pozwolić na użycie kryptograficznie słabych kluczy lub nadmierne zużycie CPU i pamięci podczas przetwarzania spreparowanych wiadomości WS-Security.

Apache WSS4J w wersjach przed 1.6.17 oraz 2.0.x przed 2.0.2 niewłaściwie ujawnia informacje o niepowodzeniach deszyfrowania, co ułatwia zdalnym atakującym odzyskanie postaci jawnej klucza symetrycznego.