CVE-2026-71891 in Bouncy Castle Java
Summary
by MITRE • 10/03/2026
In Bouncy Castle for Java before 1.86, BLS12_381BasicScheme.keyValidate, and so BLSPublicKeyParameters and every BasicScheme, MessageAugmentation and ProofOfPossession verify and aggregateVerify that gate on it, accepted a public key built on a foreign ECCurve that merely shares BLS12-381's field characteristic. The prime-order subgroup check trusts a point's own curve to name its cofactor, since ECPoint.satisfiesOrder returns true outright when the curve's cofactor is one, so a point on a curve with a different equation and a cofactor forged to one passed keyValidate despite not being a G1 point at all. In BC's pairing implementation such a point contributes the identity in the target group, so an aggregate signature verified against a set of public keys including it is accepted even though it contains no signature for that key and message pair, admitting a phantom signer. keyValidate now first confirms that the point's curve carries exactly the canonical G1 field, equation, order and cofactor before any subgroup check. The issue is reachable only where an application constructs an ECPoint on an explicit, non-canonical curve and accepts it as an authority-bearing key; the standard 48-byte compressed-point decoder always supplies the canonical curve and was never affected.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java prior to version 1.86 represents a critical flaw in the cryptographic validation logic governing the BLS12-381 signature scheme, specifically affecting public key verification processes such as those found in BLSPublicKeyParameters and various BasicScheme implementations including MessageAugmentation and ProofOfPossession. The core technical deficiency lies within the keyValidate method, which failed to rigorously enforce that a provided elliptic curve point resides on the canonical BLS12-381 G1 curve. Instead of validating against the strict mathematical definition of the standard curve, the implementation accepted public keys constructed from foreign elliptic curves that merely shared the same field characteristic as BLS12-381. This oversight allowed an attacker to introduce a point defined on a non-canonical curve into the verification pipeline, bypassing essential security checks designed to ensure cryptographic integrity and authenticity of signers.
The operational mechanism enabling this exploit relies on how the library handles cofactor multiplication and subgroup validation within its elliptic curve arithmetic engine. The function ECPoint.satisfiesOrder is responsible for verifying that a point belongs to the prime-order subgroup by checking if multiplying it by the cofactor yields the identity element. In standard BLS12-381 implementations, the cofactor is greater than one, necessitating this check to eliminate small-subgroup attacks and ensure points are valid generators of the intended group. However, in the vulnerable version, when a point was defined on an explicit curve where the cofactor parameter was artificially set or calculated as one, the satisfiesOrder function returned true immediately without performing further validation against the canonical G1 parameters. Consequently, a malicious actor could craft a public key using a custom elliptic curve equation with a forged cofactor of one, thereby tricking the library into accepting it as a valid BLS12-381 public key despite it not being an element of the correct mathematical group structure.
The security impact of this flaw is severe, particularly in systems relying on signature aggregation and batch verification mechanisms common in blockchain consensus protocols and distributed ledger technologies. When such a forged public key was included in a set of keys used for aggregate signature verification, the pairing-based cryptographic operations would treat the point as contributing the identity element to the target group calculation. This mathematical property effectively nullifies the contribution of that specific key to the overall verification equation. As a result, an attacker could generate a valid aggregate signature that omits their own individual signature component while still passing validation against the set of public keys. This creates a phantom signer scenario where the system accepts signatures as authentic even though they were not actually signed by the purported authority bearing the forged key, thereby undermining non-repudiation and trust assumptions inherent in digital signature schemes.
This vulnerability is classified under CWE-295 Improper Certificate Validation because it involves accepting an entity with invalid or improperly validated credentials within a cryptographic context. Furthermore, from a threat modeling perspective aligned with MITRE ATT&CK techniques, this flaw facilitates Identity Impersonation (T1078) and potentially impacts Integrity via Tampering if the system relies on these signatures for access control or transaction finality. The attack vector is specifically relevant to applications that manually construct ECPoint objects using explicit curve parameters rather than relying on standard decoding routines. It does not affect users of the standard 48-byte compressed-point decoder, which inherently supplies points defined over the canonical BLS12-381 curve with correct structural properties, thus limiting the exposure primarily to custom implementations or advanced cryptographic integrations that bypass default parsing mechanisms.
To mitigate this risk, organizations utilizing affected versions of Bouncy Castle must upgrade immediately to version 1.86 or later, where the keyValidate method has been hardened to explicitly confirm that any incoming point resides on a curve with exactly the canonical G1 field characteristic, equation coefficients, group order, and cofactor before proceeding with subgroup checks. For applications unable to update libraries instantly, defensive coding practices should be adopted by ensuring all public keys are derived through standard decoding functions rather than manual construction of elliptic curve points. Additionally, developers implementing custom cryptographic workflows involving BLS signatures should implement independent validation layers that verify the mathematical consistency of curve parameters against known standards before passing them to library verification routines, thereby adding a layer of defense-in-depth against malformed or maliciously crafted inputs designed to exploit arithmetic edge cases in pairing-based cryptography implementations.