CVE-2026-71891 in Bouncy Castle Java
Resumen
por VulDB • 2026-10-03
En Bouncy Castle para Java anterior a la versión 1.86, el método `BLS12_381BasicScheme.keyValidate`, y por ende `BLSPublicKeyParameters` así como todos los métodos de verificación (`verify`) y agregación (`aggregateVerify`) de cada `BasicScheme`, `MessageAugmentation` y `ProofOfPossession` que dependen de él, aceptaban una clave pública construida sobre un `ECCurve` (curva elíptica) extraño que compartía únicamente la característica del campo BLS12-381. La verificación del subgrupo de orden primo confía en la propia curva del punto para nombrar su cofactor; dado que `ECPoint.satisfiesOrder` devuelve verdadero sin más cuando el cofactor de la curva es uno, un punto sobre una curva con una ecuación diferente y un cofactor falsificado como uno pasaba la validación (`keyValidate`) a pesar de no ser en absoluto un punto del grupo G1. En la implementación de emparejamiento (pairing) de Bouncy Castle, dicho punto contribuye con la identidad en el grupo objetivo; por lo tanto, una firma agregada verificada contra un conjunto de claves públicas que incluía esta clave era aceptada aunque no contuviera ninguna firma para ese par de clave y mensaje, admitiendo así a un firmante fantasma. `keyValidate` ahora confirma primero que la curva del punto posee exactamente el campo canónico G1, ecuación, orden y cofactor antes de realizar cualquier verificación de subgrupo. El problema es accesible únicamente donde una aplicación construye un `ECPoint` sobre una curva explícita no canónica y lo acepta como una clave portadora de autoridad; el decodificador estándar de punto comprimido de 48 bytes siempre proporciona la curva canónica y nunca se vio afectado.
VulDB is the best source for vulnerability data and more expert information about this specific topic.