CVE-2026-71885 in BC-JAVA
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java anterior à versão 1.86, a implementação do Messaging Layer Security (MLS, RFC 9420) não vinculava uma credencial X.509 à `signature_key` de um LeafNode. O método `LeafNode.verify()` verificava a assinatura de um leaf em relação à `signature_key` contida no próprio leaf, enquanto a cadeia de certificados X.509 da credencial era armazenada, mas nunca analisada ou validada; portanto, a chave pública do certificado final (end-entity) não era exigida para corresponder à `signature_key`, conforme requerido pela RFC 9420 seção 5.3. Uma parte poderia, assim, apresentar o certificado de outra parte como sua credencial enquanto assinava o leaf e o KeyPackage envolvente com uma chave não relacionada, sendo aceita sob a identidade dessa outra parte através do método `KeyPackage.verify()` e do caminho de validação de leaves do grupo. Em um ambiente que admite commits externos sem uma verificação independente da admissão de credenciais, um atacante não autenticado poderia ser admitido sob a identidade X.509 de uma vítima, expulsar a vítima (a resincronização compara credenciais inteiras em vez das chaves de assinatura), derivar o epoch atual, decifrar mensagens subsequentes do grupo e enviar mensagens aceitas como sendo da vítima. O `TreeKEM.LeafNode` agora exige que a chave pública do assunto do certificado final, na codificação de assinatura do cipher suite, seja igual à `signature_key` para uma credencial X.509 e rejeita o leaf caso contrário, incluindo cadeias vazias ou certificados cujo tipo de chave não corresponda ao cipher suite; a validação da cadeia de certificados e da identidade até um anchor de confiança permanece responsabilidade do aplicativo conforme RFC 9420 seção 5.3.1. Ambientes que utilizam apenas credenciais básicas não são afetados.
If you want to get best quality of vulnerability data, you may have to visit VulDB.