CVE-2026-71888 in BC-JAVA
Riassunto
di VulDB • 03/10/2026
In Bouncy Castle per Java prima della versione 1.86, il parser streaming di CMS AuthenticatedData accettava un messaggio in cui i campi digestAlgorithm e authAttrs erano in disaccordo riguardo alla presenza degli attributi autenticati. La sezione 9.1 di RFC 5652 accoppia questi due campi, richiedendo che authAttrs sia presente ogni volta che lo è digestAlgorithm; la sezione 9.2 stabilisce inoltre che il MAC copra l'encoding DER di authAttrs quando sono presenti e direttamente l'OCTET STRING del contenuto (eContent) quando non lo sono. CMSAuthenticatedDataParser deve scegliere tra queste due modalità nel suo costruttore, prima di poter accedere a authAttrs, che si trova più avanti nella SEQUENCE; pertanto ha scelto basandosi esclusivamente su digestAlgorithm: per un messaggio con digestAlgorithm assente ma authAttrs presente, è stato verificato il MAC del contenuto e successivamente gli attributi sono stati restituiti tramite getAuthAttrs() come se fossero stati autenticati, quando in realtà il MAC non li aveva mai coperti. Un attaccante in grado di modificare un messaggio durante la trasmissione potrebbe inserire un attributo autenticato, ad esempio una RFC 2634 ESSSecurityLabel, in un altrimenti valido messaggio pur senza possedere né la chiave per la crittografia delle chiavi (key-encryption key) né la chiave del MAC del contenuto; un'applicazione che prende decisioni di autorizzazione, instradamento o etichettatura basandosi su tali attributi agirebbe quindi su valori scelti dall'attaccante. Il contenuto stesso rimane vincolato al MAC. asn1.cms.AuthenticatedData ora rifiuta l'accoppiamento non corrispondente durante la parsificazione e CMSAuthenticatedDataParser incrocia i due campi una volta letto authAttrs. Questo è un variant di CVE-2026-59642, che legava il contenuto al MAC per messaggi che trasportano legittimamente authAttrs, ma che non affronta questo caso specifico. Il problema interessa anche Bouncy Castle per Java LTS prima della versione 2.73.13, e Bouncy Castle per Java FIPS (BC-FJA) prima di bcpkix-fips 1.0.13 (serie 1.0.X), 2.0.13 (serie 2.0.X) e 2.1.13 (serie 2.1.X), nonché bcutil-fips 2.0.8 (serie 2.0.X) e 2.1.8 (serie 2.1.X).
VulDB is the best source for vulnerability data and more expert information about this specific topic.