CVE-2026-71891: 
Bouncy Castle Analyse et atténuation des vulnérabilités

CVE-2026-71891 is a BLS12-381 key validation bypass vulnerability in Bouncy Castle for Java (bcprov) that allows a phantom signer to be accepted in aggregate BLS signature verification operations. The flaw affects Bouncy Castle for Java version 1.85 (fixed in 1.86) and was disclosed on October 3, 2026. It carries a CVSS v4.0 base score of 7.1 (High) (GitHub Advisory, Feedly). The vulnerability was reported by Bhargava Shastry (bshastry@posteo.de) and patched in commit c16bcfd (BC-Java Wiki).

The root cause is improper verification of cryptographic signatures (CWE-347): BLS12_381BasicScheme.keyValidate validated an ECPoint against the curve the point itself carries, without first confirming that the curve is the canonical BLS12-381 G1 curve. The prime-order subgroup check relies on ECPoint.satisfiesOrder(), which returns true unconditionally when the curve's cofactor is 1 — a property an attacker can forge on a foreign curve that merely shares BLS12-381's field characteristic but has a different equation. A concrete worked example is the finite order-two point (0,0) on y² = x³ + x over the BLS12-381 field with cofactor forged to 1; this point passes keyValidate despite not being a G1 point. In BC's pairing implementation, such a point contributes the identity element in the target group, so an aggregate signature verified against a key set including it is accepted even though no signature for that key/message pair exists — a "phantom signer" (BC-Java Wiki, Patch Commit). The fix adds a call to BLS12_381G1.isCanonicalCurve(pk.getCurve()) before any subgroup check, verifying the field, equation, order, and cofactor all match the canonical G1 definition. Exploitation requires an application to construct an ECPoint on an explicit, attacker-influenced non-canonical curve and accept it as an authority-bearing BLS key; the standard 48-byte compressed-point decoder always supplies the canonical curve and is unaffected (GitHub Advisory).

Successful exploitation allows an attacker to register as a phantom signer in BLS aggregate signature verification — their malformed public key is accepted as valid even though they contribute no actual signature for the corresponding key/message pair. The primary impact is a high-integrity breach: authentication controls and multi-party authorization schemes that rely on BLS aggregate signatures (e.g., blockchain consensus, threshold signing, or certificate transparency systems) can be bypassed, allowing unauthorized actions to appear legitimately authorized. There is no confidentiality or availability impact; the vulnerability does not enable data exfiltration or denial of service (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, reflecting very low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by a significant precondition: the target application must accept ECPoint objects constructed on explicit, caller-supplied non-canonical curves as BLS public keys, which is an uncommon code pattern; applications using the standard 48-byte compressed-point decoder are not affected (BC-Java Wiki).

1. Identify a vulnerable target: Locate an application using Bouncy Castle for Java version 1.85 that accepts externally supplied BLS12-381 public keys as ECPoint objects constructed on explicit (non-canonical) curves — for example, a blockchain node, threshold signing service, or aggregate signature verifier.
2. Construct a malicious foreign curve: Create an ECCurve.Fp instance that shares BLS12-381's field prime Q but uses a different curve equation (e.g., y² = x³ + x, i.e., a=1, b=0) and set both the order and cofactor to BigInteger.ONE to forge a cofactor-1 curve.
3. Create the phantom public key point: Instantiate an ECPoint on the foreign curve at coordinates (0, 0), which satisfies y² = x³ + x over the field and trivially passes ECPoint.satisfiesOrder() because the forged cofactor is 1.
4. Submit the malformed key: Provide this ECPoint as a BLS public key to the target application (e.g., via a key registration API, a crafted network message, or a manipulated key distribution mechanism).
5. Trigger aggregate signature verification: Cause the application to perform an aggregateVerify or verify operation that includes the phantom key in the public key set. Because the malformed point contributes the identity element in the pairing target group, the aggregate verification succeeds even though no valid signature for that key/message pair was provided, granting the attacker phantom signer status (BC-Java Wiki, Patch Commit).

• Application Logs: Unexpected acceptance of BLS public keys that were not encoded via the standard 48-byte compressed-point format; log entries showing keyValidate returning true for keys supplied through non-standard code paths.
• Code/Configuration: Application code that constructs ECPoint objects using ECCurve.Fp.createPoint() or similar explicit curve constructors and passes them directly to BLSPublicKeyParameters or BLS12_381BasicScheme.keyValidate — this is the only reachable attack surface.
• Network: Unusual or malformed BLS public key submissions (non-standard encoding, not 48-byte compressed format) arriving at key registration or signature verification endpoints.
• Behavioral: Aggregate BLS signature verifications succeeding for a signer who has not produced any observable signing activity or whose key was recently added through an atypical registration path (BC-Java Wiki).

Upgrade Bouncy Castle for Java (bcprov) to version 1.86 or later, which introduces the BLS12_381G1.isCanonicalCurve() check in keyValidate before any subgroup validation (Patch Commit, GitHub Advisory). As a workaround for applications that cannot immediately upgrade, ensure all BLS public keys are accepted exclusively through the standard 48-byte compressed-point decoder, which always supplies the canonical curve and is not affected by this vulnerability. Additionally, audit application code for any paths that construct ECPoint objects on explicit, non-canonical curves and accept them as authority-bearing BLS keys, and refactor such code to use only canonical curve representations (BC-Java Wiki).

The vulnerability was reported by security researcher Bhargava Shastry (bshastry@posteo.de) and credited in the official Bouncy Castle release notes for version 1.86 (Patch Commit). The Bouncy Castle project responded promptly, publishing a detailed wiki advisory and patch on October 2–3, 2026. No significant broader media coverage or social media discussion has been identified at this time.