CVE-2026-71892 in BC-JAVA
Sumário
de VulDB • 04/10/2026
No Bouncy Castle para Java anterior à versão 1.86, a validação de tamanho da chave opt-in em destinatários de transporte de chaves CMS, `org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true)`, nunca foi executada para uma mensagem que utilizava derivação de chave de criptografia de conteúdo conforme RFC 9709 (id-alg-cek-hkdf-sha256). O ramo que deveria selecionar o algoritmo real de criptografia de conteúdo contido nos parâmetros do AlgorithmIdentifier da derivação de chaves comparava a matriz de bytes da chave criptografada contra o identificador de objeto id-alg-cek-hkdf-sha256, uma comparação entre uma matriz de bytes e um ASN1ObjectIdentifier que é falsa para qualquer entrada possível. Assim, a verificação caía em uma consulta ao tamanho da chave no OID do wrapper externo. Esse OID identifica uma construção de derivação de chaves, não um cipher (cifra), e não possui um tamanho de chave registrado; portanto, a comparação de tamanhos foi ignorada completamente. Um EnvelopedData ou AuthEnvelopedData com transporte de chave cuja chave HKDF-derivada para criptografia de conteúdo não correspondia ao tamanho da chave do algoritmo de criptografia de conteúdo anunciado era aceito mesmo com a validação explicitamente habilitada, derrotando silenciosamente o único mecanismo oferecido pela API para impor o tamanho da chave recuperada. O destinatário agora faz dispatch (despacho) no OID do algoritmo do AlgorithmIdentifier de criptografia de conteúdo, de modo que as verificações de validação comparam a chave recuperada contra o algoritmo interno de criptografia de conteúdo. Mensagens com tamanho de chave correspondente, mensagens não-HKDF e destinatários que não habilitam a validação não são afetados. Este problema também afeta o Bouncy Castle para Java FIPS (BC-FJA) anterior às versões bcpkix-fips 2.0.13 (série 2.0.X) e 2.1.13 (série 2.1.X).
If you want to get best quality of vulnerability data, you may have to visit VulDB.