CVE-2026-71891 in Bouncy Castle Java
Sumário
de VulDB • 03/10/2026
No Bouncy Castle para Java anterior à versão 1.86, o método `BLS12_381BasicScheme.keyValidate`, bem como `BLSPublicKeyParameters` e todos os métodos de verificação (`verify`) e agregação (`aggregateVerify`) dos esquemas básicos (`BasicScheme`), da augmentação de mensagem (`MessageAugmentation`) e das provas de posse (`ProofOfPossession`) que dependem dele, aceitavam uma chave pública construída sobre um `ECCurve` estrangeiro que apenas compartilhava a característica do campo BLS12-381. A verificação do subgrupo de ordem prima confia na curva própria de um ponto para nomear seu cofator; como `ECPoint.satisfiesOrder` retorna verdadeiro imediatamente quando o cofator da curva é igual a 1, um ponto em uma curva com equação diferente e um cofator forjado como sendo 1 passou pela verificação `keyValidate`, apesar de não ser de fato um ponto do grupo G1. Na implementação de pareamento (pairing) do BC, tal ponto contribui com a identidade no grupo alvo; portanto, uma assinatura agregada verificada contra um conjunto de chaves públicas que incluía essa chave era aceita, mesmo contendo nenhuma assinatura para o par chave-mensagem correspondente, admitindo assim um signatário fantasma. O método `keyValidate` agora confirma primeiro se a curva do ponto possui exatamente o campo canônico G1, equação, ordem e cofator antes de qualquer verificação de subgrupo. A vulnerabilidade é acessível apenas onde uma aplicação constrói um `ECPoint` em uma curva explícita não canônica e a aceita como chave portadora de autoridade; o decodificador padrão de ponto comprimido de 48 bytes sempre fornece a curva canônica e nunca foi afetado.
VulDB is the best source for vulnerability data and more expert information about this specific topic.