CVE-2026-71888

W Bouncy Castle dla języka Java przed wersją 1.86 parser przesyłania strumieniowego CMS AuthenticatedData akceptował wiadomość, której pola DigestAlgorithm i authAttrs nie zgadzały się co do obecności uwierzytelnionych atrybutów. RFC 5652 sek. 9.1 łączy te dwa elementy w parę, wymagając obecności elementu authAttrs za każdym razem, gdy występuje algorytm trawienia, oraz sek. 9.2 sprawia, że ​​MAC obejmuje kodowanie DER authAttrs, gdy są obecne, i bezpośrednio eContent OCTET STRING, gdy ich nie ma. CMSAuthenticatedDataParser musi wybrać pomiędzy tymi dwoma w swoim konstruktorze, zanim będzie mógł dotrzeć do authAttrs, co następuje później w SEQUENCE, więc wybrał sam DigestAlgorithm: w przypadku wiadomości z nieobecnością DigestAlgorithm, ale obecnymi authAttrs, zweryfikował zawartość MAC, a następnie zwrócił atrybuty za pomocą getAuthAttrs() tak, jakby zostały uwierzytelnione, choć MAC ich nigdy nie zakrył. Osoba atakująca, która może zmodyfikować przesyłaną wiadomość, może wstawić uwierzytelniony atrybut, taki jak RFC 2634 ESSSecurityLabel, do prawidłowej wiadomości, nie posiadając ani klucza szyfrującego klucza, ani klucza MAC zawartości, a aplikacja podejmująca decyzję o autoryzacji, routingu lub etykietowaniu na podstawie tych atrybutów będzie działać na wartościach wybranych przez osobę atakującą. Sama treść pozostała związana z adresem MAC. asn1.cms.AuthenticatedData odrzuca teraz niedopasowane pary podczas analizowania, a CMSAuthenticatedDataParser sprawdza krzyżowo oba pola po odczytaniu authAttrs. Jest to wariant CVE-2026-59642, który powiązał treść z adresem MAC w przypadku wiadomości, które legalnie zawierają atrybuty authAttr, i który nie dotyczy tego przypadku. Ten problem dotyczy także Bouncy Castle dla Java LTS przed 2.73.13 i Bouncy Castle dla Java FIPS (BC-FJA) przed bcpkix-fips 1.0.13 (seria 1.0.X), 2.0.13 (seria 2.0.X) i 2.1.13 (seria 2.1.X) oraz bcutil-fips 2.0.8 (seria 2.0.X) i 2.1.8 (seria 2.1.X).