In Bouncy Castle for Java versions prior to 1.86, the keyValidate method in BLS12_381BasicScheme and related classes incorrectly trusts the curve's cofactor property without verifying the curve's canonical parameters. This allows a crafted public key on a foreign elliptic curve with a forged cofactor of one to pass validation despite not being a valid G1 point. Because the pairing implementation treats such points as contributing the identity element, aggregate signature verification can be tricked into accepting signatures that include phantom signers. The vulnerability is exploitable only when applications construct ECPoints on explicit, non-canonical curves and accept them as authority-bearing keys; the standard 48-byte compressed-point decoder always uses the canonical curve and is not affected. The fix in version 1.86 adds explicit checks that the point's curve matches the canonical G1 field, equation, order, and cofactor before subgroup validation.

An attacker can craft a public key on a non-canonical curve that passes key validation and contributes the identity element in pairing operations. This allows aggregate signature verification to accept signatures that include phantom signers, potentially undermining signature authenticity checks. However, exploitation requires the application to explicitly construct ECPoints on non-canonical curves and accept them as valid keys. Standard usage with the compressed-point decoder is not vulnerable.

Upgrade Bouncy Castle for Java to version 1.86 or later, where keyValidate performs strict checks on the curve parameters before subgroup validation. Applications should avoid constructing ECPoints on explicit, non-canonical curves and should rely on the standard compressed-point decoder, which is not affected by this vulnerability. No other mitigation is required if these conditions are met.