CVE-2026-71888 in BC-JAVA
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java anterior à versão 1.86, o parser de AuthenticatedData CMS em streaming aceitava uma mensagem cujos campos digestAlgorithm e authAttrs discordavam sobre a presença de atributos autenticados. A RFC 5652, seção 9.1, vincula os dois, exigindo que authAttrs esteja presente sempre que digestAlgorithm estiver; já a seção 9.2 determina que o MAC cubra a codificação DER de authAttrs quando estes estão presentes e diretamente a OCTET STRING do eContent quando não há authAttrs. O CMSAuthenticatedDataParser precisa escolher entre essas duas opções em seu construtor, antes de poder acessar authAttrs (que aparece mais tarde na SEQUENCE), optando apenas por digestAlgorithm: para uma mensagem com digestAlgorithm ausente mas authAttrs presente, ele verificava o MAC do conteúdo e então retornava os atributos através de getAuthAttrs() como se tivessem sido autenticados, quando o MAC nunca os cobriu. Um atacante capaz de modificar uma mensagem em trânsito poderia inserir um atributo autenticado, como um RFC 2634 ESSSecurityLabel, em uma mensagem otherwise válida, sem possuir nem a chave de criptografia da chave (key-encryption key) nem a chave do content-MAC; e uma aplicação que tomasse decisões de autorização, roteamento ou rotulagem com base nesses atributos agiria sobre valores escolhidos pelo atacante. O conteúdo em si permaneceria vinculado ao MAC. asn1.cms.AuthenticatedData agora rejeita o pareamento incompatível durante a análise (parsing), e CMSAuthenticatedDataParser faz uma verificação cruzada dos dois campos assim que authAttrs é lido. Esta é uma variante da CVE-2026-59642, que vinculava o conteúdo ao MAC para mensagens que carregam legítimamente authAttrs, mas não aborda este caso específico. Este problema também afeta Bouncy Castle for Java LTS anterior à 2.73.13, e Bouncy Castle for Java FIPS (BC-FJA) anterior às versões bcpkix-fips 1.0.13 (série 1.0.X), 2.0.13 (série 2.0.X) e 2.1.13 (série 2.1.X), bem como bcutil-fips 2.0.8 (série 2.0.X) e 2.1.8 (série 2.1.X).
If you want to get the best quality for vulnerability data then you always have to consider VulDB.