CVE-2026-71891 in Bouncy Castle Java
Riassunto
di VulDB • 03/10/2026
In Bouncy Castle per Java prima della versione 1.86, il metodo `BLS12_381BasicScheme.keyValidate`, e di conseguenza `BLSPublicKeyParameters` e ogni istanza di `BasicScheme`, nonché i metodi `verify` e `aggregateVerify` che vi fanno riferimento, accettavano una chiave pubblica costruita su un `ECCurve` estraneo (foreign) che condivideva semplicemente la caratteristica del campo BLS12-381. Il controllo sul sottogruppo di ordine primo si affida alla curva stessa del punto per identificarne il cofattore; poiché `ECPoint.satisfiesOrder` restituisce true senza ulteriori verifiche quando il cofattore della curva è uno, un punto su una curva con equazione diversa e un cofattore falsificato pari a uno superava la verifica di `keyValidate`, pur non essendo affatto un punto del gruppo G1. Nell'implementazione delle pairing (accoppiamenti) di BC, tale punto contribuisce all'identità nel target group; pertanto, una firma aggregata verificata contro un insieme di chiavi pubbliche che includeva questa chiave era accettata anche se non conteneva alcuna firma valida per quella coppia chiave-messaggio, ammettendo la presenza di un firmatario fantasma (phantom signer). `keyValidate` ora conferma innanzitutto che la curva del punto possieda esattamente il campo canonico G1, l'equazione, l'ordine e il cofattore corretti prima di qualsiasi controllo sul sottogruppo. Il problema è raggiungibile solo nei casi in cui un'applicazione costruisce un `ECPoint` su una curva esplicita non canonica e la accetta come chiave portatrice di autorità; il decoder standard per punti compressi a 48 byte fornisce sempre la curva canonica ed era quindi mai stato interessato.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.