CVE-2026-71884

W Bouncy Castle dla Java LTS przed wersją 2.73.13 natywny jednorazowy szyfr pakietowy CTR nie sprawdzał, czy żądana długość wejściowa pasuje do miejsca licznika pozostawionego przez IV. W trybie CTR IV i licznik bloków współdzielą jeden 16-bajtowy blok, więc IV od 13 do 15 bajtów pozostawia licznik tylko od 1 do 3 bajtów, adresując odpowiednio 256, 65536 lub 16777216 bloków. Biorąc pod uwagę dłuższe dane wejściowe, licznik został zawinięty, a strumień klucza powtórzony od początku tego samego pakietu, a następnie wywołanie zwróciło pełną długość wejściową, tak jakby każdy bajt został poprawnie przekształcony. Dlatego dwa segmenty wiadomości zostały zaszyfrowane przy użyciu tego samego strumienia klucza, więc ich teksty jawne można odzyskać z samego tekstu zaszyfrowanego, bez klucza, podczas gdy osoba dzwoniąca nie widziała ani wyjątku, ani krótkiej długości, aby to wskazać. Implementacja przesyłania strumieniowego sprawdza poprawność podczas inicjowania i ponownie podczas przetwarzania, a przenośny AESCTRPacketCipher odrzuca takie żądanie z komunikatem „Licznik w trybie CTR/SIC poza zasięgiem.”, ale natywna ścieżka jednorazowa ma pojedynczy punkt wejścia i nie przeprowadziła tam żadnej weryfikacji licznika zakresu. Teraz przeprowadza wstępną inspekcję zakresu licznika pochodzącego z IV i odrzuca zbyt długie żądanie przed zapisaniem jakichkolwiek danych wyjściowych, więc operacja ma charakter atomowy i nigdy nie zgłasza powodzenia w przypadku bajtów, których nie została poprawnie przekształcona. Licznik o długości czterech lub więcej bajtów nie może zostać wyczerpany przez długość int Java i nie ma na to wpływu, podobnie jak w przypadku pełnego 16-bajtowego IV, gdzie za zakres licznika odpowiada osoba wywołująca. Nie ma to wpływu na Bouncy Castle for Java (bcprov), ponieważ nie zawiera żadnych natywnych implementacji.