Cloudanix VulnDB

CVE-2026-71891

None

CVSS

—

EPSS

0.2%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Monitor only SSVC: Track

A cryptography library bug could let attackers slip in fake keys that make group signature checks pass even when a required signature is missing.

Chainable
Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Moderate
Impact
Data Tampering
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The flaw permits an ECPoint constructed on a non-canonical curve sharing only the BLS12-381 field characteristic to pass keyValidate (and downstream verify/aggregateVerify calls) because the cofactor check trusts the point's own curve; the point contributes the identity element in the pairing target group, allowing an aggregate signature to verify without a corresponding signature for that key/message.

Why it matters to the business

Systems relying on BLS aggregate signatures for authentication or consensus may accept forged or incomplete signatures, undermining trust in cryptographic operations and potentially enabling unauthorized actions in high-assurance environments.

How an attack unfolds

An attacker supplies a specially crafted public key built on a foreign curve that shares the BLS12-381 prime; when the application passes this key to keyValidate or aggregate verification routines, the point is accepted despite not lying on the canonical G1 curve; during pairing it evaluates to identity, so the aggregate signature validates even though the attacker never produced a valid signature for that key.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later; after upgrade, ensure all BLS public-key handling uses only the library's standard 48-byte compressed-point decoder or the updated keyValidate that enforces canonical G1 parameters before any subgroup check.

How to confirm the fix worked

Confirm the Bouncy Castle jar version is 1.86 or newer; unit-test keyValidate with a point on a non-canonical curve sharing the BLS12-381 characteristic and verify it is rejected; re-run all BLS aggregate signature test vectors.

Typical attack path

  1. Locate an application that constructs or accepts ECPoints on explicit curves and feeds them into BLS12-381 BasicScheme, MessageAugmentation or ProofOfPossession routines
  2. Craft a point on a foreign curve sharing only the field characteristic with BLS12-381 and set its curve cofactor to 1
  3. Present the point as an authority-bearing public key to the vulnerable keyValidate or aggregateVerify call
  4. Submit an aggregate signature that omits any contribution from the phantom key; verification succeeds because the point contributes the identity

How to detect it

Search application logs, source code and dependency manifests for explicit construction of ECPoint or BLS public-key objects outside the standard compressed decoder; monitor for any use of BLS12-381 keyValidate or aggregateVerify with keys sourced from untrusted input.

What your security team should do

  • Immediately inventory all Java applications that depend on Bouncy Castle and use BLS12-381 schemes
  • Upgrade to Bouncy Castle 1.86+ in the next maintenance window; treat as high priority for any authentication or consensus use case
  • Audit custom ECPoint construction code paths that bypass the standard decoder
  • Add regression tests that feed non-canonical points to keyValidate and aggregateVerify

The record

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.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities