CVE-2026-87830

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 procesorze bezpieczeństwa DOM w Apache WSS4J występuje obejście uwierzytelniania, które pozwala nieuwierzytelnionym zdalnym atakującym na fałszowanie uwierzytelnionych wiadomości SOAP poprzez spreparowaną, niepodpisaną asercję SAML sender-vouches zawierającą klucz kontrolowany przez atakującego.

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.