In Bouncy Castle for Java before version 1.86, the keyValidate method in BLS12_381BasicScheme and related classes accepted public keys built on foreign elliptic curves that share the BLS12-381 field characteristic but differ in curve equation and cofactor. The subgroup check trusted the curve's cofactor value, which could be forged to one, causing ECPoint.satisfiesOrder to return true incorrectly. Consequently, points not on the canonical G1 curve passed validation. In the pairing implementation, such points contribute the identity element, allowing aggregate signature verification to succeed despite missing valid signatures for those keys, effectively admitting phantom signers. The fix in version 1.86 enforces that the point's curve matches the canonical G1 field, equation, order, and cofactor before subgroup validation. This vulnerability is only reachable if applications construct ECPoints on explicit, non-canonical curves and accept them as valid keys; the standard 48-byte compressed-point decoder always uses the canonical curve and is unaffected.

An attacker can exploit this vulnerability to forge aggregate signatures that include phantom signers, bypassing signature verification checks. This undermines the integrity of cryptographic operations relying on BLS12-381 signatures in affected Bouncy Castle Java versions. However, exploitation requires the application to explicitly construct ECPoints on non-canonical curves and accept them as valid public keys. Standard usage with the compressed-point decoder is not vulnerable. There are no known exploits in the wild.

Upgrade Bouncy Castle for Java to version 1.86 or later, where the keyValidate method enforces strict curve parameter validation before subgroup checks. If upgrading is not immediately possible, ensure that applications do not construct ECPoints on explicit, non-canonical curves or accept such points as valid public keys. The standard compressed-point decoder remains safe. No other mitigation is indicated by the vendor.