A flaw in Bouncy Castle’s Java library allows the keyValidate routine to accept a public key constructed from an elliptic curve that shares the field characteristic of BLS12‑381 but has a different curve equation and a forged cofactor of one. Because ECPoint.satisfiesOrder returns true for such points, they pass the subgroup check even though they are not elements of the intended G1 subgroup. In the pairing implementation this causes the point to contribute the identity element in the target group, so an aggregate signature that includes this key is erroneously considered valid. Consequently, an attacker can introduce a phantom signer and have signatures for messages validated without actually signing them, undermining authenticity and non‑repudiation.

The bug affects the Bouncy Castle BLS12‑381 implementation for Java (BC‑JAVA) in versions prior to 1.86. It impacts the keyValidate routine used by BLSPublicKeyParameters, BasicScheme, MessageAugmentation, and ProofOfPossession verify functions, which are part of the standard library. Applications that load or construct public keys directly using ECPoint on a non‑canonical curve could be impacted, while normal compressed‑point decoding is not affected.

This vulnerability has a CVSS score of 7.1, indicating moderate to high severity. EPSS is not available, and it is not listed in CISA KEV. Exploitation requires an application to explicitly create an ECPoint on a non‑canonical curve and treat it as a valid public key; standard key loading functions do not trigger the issue. While the attack surface is limited to code that accepts custom curve points, it remains serious for cryptographic libraries that rely on untrusted key material, making a patch or strict validation highly recommended.