CVE-2026-71890 in BC-JAVA
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java anterior à versão 1.86, a validação da lista de propostas do commit externo MLS (RFC 9420), através da função `org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals`, contava as propostas por tipo e limitava o índice da folha removida, mas nunca estabelecia que a folha removida tivesse alguma relação com o participante que ingressa na rede (joiner). A RFC 9420, secção 12.2, permite no máximo uma proposta de remoção num commit externo, através da qual o joiner remove uma versão antiga de si próprio, e exige que, quando tal está presente, o LeafNode no campo path do commit satisfaça os critérios que teria de satisfazer numa atualização para a folha removida, nomeadamente que as suas credenciais apresentem identificadores aceitáveis para o participante removido. A regra de auto-remoção do validador ordinário da lista de propostas não é aplicada deliberadamente neste caminho, porque um commit de resincronização remove legitimamente uma folha possuída pelo joiner, mas nada foi colocado no seu lugar. Qualquer parte que detenha as credenciais públicas do GroupInfo (que é precisamente o que se espera ser fornecido a um novo membro externo) poderia, portanto, executar uma remoção indicando qualquer LeafIndex de outro membro e fazer com que todos os membros a apliquem, expulsando esse membro e assumindo a sua posição na árvore ratchet. A verificação de credenciais que deveria ter impedido esta situação existia apenas no harness de interop gRPC, protegendo assim nenhum outro chamador das APIs públicas `Group.externalJoin` e `Group.handle`. Um commit externo que contenha uma remoção é agora aceite apenas quando as credenciais da folha removida são idênticas às do novo leaf próprio do joiner, tanto no lado de envio como no lado de recepção.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.