CVE‐2026‐71891

Title: BLS12-381 key validation accepts a public key built on a foreign curve.

Issue affecting: BC before 1.86 (from 1.85).

Fixed versions: BC 1.86.

Platform affected: Java 8 and later.

BLS12_381BasicScheme.keyValidate is the gate every BLS verification path runs before trusting a public key — BLSPublicKeyParameters construction, and verify / aggregateVerify across BasicScheme, MessageAugmentation and ProofOfPossession. It validated a generic ECPoint against the curve the point itself carries, without establishing that the curve is BLS12-381 G1.

The prime-order subgroup check is what makes that omission exploitable. ECPoint.satisfiesOrder() returns true outright when the curve's cofactor is one, on the reasoning that every point on a cofactor-1 curve is in the prime-order subgroup. That reasoning is sound only for a curve you already trust. A caller-supplied curve names its own cofactor, so a foreign curve sharing BLS12-381's field characteristic but carrying a different equation and a cofactor forged to one passed the check trivially — the finite order-two point (0,0) on y^2 = x^3 + x is the worked example.

In BC's pairing implementation such a point contributes the identity element in the target group. An aggregate signature verified against a set of public keys that includes it is therefore accepted even though the aggregate contains no signature for that public-key/message row: a phantom signer, present in the verified set, contributing nothing.

keyValidate now confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor (BLS12_381G1.isCanonicalCurve) before any subgroup check is attempted.

Reachability is limited. The standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected; the issue requires an application to construct an ECPoint on an explicit, attacker-influenced curve and then accept it as an authority-bearing BLS key.

The fix was introduced in commit c16bcfdce1f9.

Credit: Bhargava Shastry.