Cloudanix VulnDB

CVE-2026-71885

None

CVSS

—

EPSS

0.2%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a widely used cryptography library could let attackers pretend to be someone else inside encrypted group chats, read private messages, and send messages that appear to come from the real person.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Exposure
Component
Library
Class
Authentication Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

The MLS implementation failed to enforce that an X.509 credential's end-entity public key matches the LeafNode signature_key; LeafNode.verify and KeyPackage.verify accepted a leaf signed with an unrelated key while carrying another party's certificate, violating RFC 9420 section 5.3.

Why it matters to the business

Organizations using Bouncy Castle MLS for secure group messaging risk identity impersonation, message decryption, and unauthorized participation that can expose confidential communications and allow attackers to masquerade as legitimate members.

How an attack unfolds

An attacker generates a LeafNode and KeyPackage that references a victim's X.509 certificate but signs both structures with a key the attacker controls; because certificate public-key binding is not enforced, KeyPackage.verify and the group leaf-validation path accept the structures. In deployments that allow external commits without extra credential checks the attacker joins under the victim's identity, evicts the real owner via resynchronization, derives the current epoch secret, and can decrypt or inject messages accepted as originating from the victim.

How to fix it

Upgrade Bouncy Castle for Java to version 1.86 or later; the updated TreeKEM.LeafNode now requires the end-entity certificate subject public key to equal signature_key for X.509 credentials. Applications remain responsible for full certificate-chain validation to a trust anchor.

How to confirm the fix worked

Confirm Bouncy Castle version 1.86 or newer is in use; test that LeafNode and KeyPackage objects containing mismatched certificate and signature_key are rejected; verify that existing basic-credential flows continue to operate.

Typical attack path

  1. Craft LeafNode and KeyPackage containing victim's X.509 credential but signed with attacker-controlled key
  2. Submit the malicious KeyPackage via an external commit accepted by the group
  3. Pass LeafNode.verify and KeyPackage.verify because signature_key binding is not checked
  4. Trigger resynchronization to evict the legitimate owner
  5. Derive epoch secret and decrypt or send messages under the victim's identity

How to detect it

Search application and MLS protocol logs for KeyPackage or LeafNode objects that were accepted with X.509 credentials; look for rapid membership changes followed by resynchronization events or unexpected message decryption under a single identity.

What your security team should do

  • Immediately inventory all deployments that embed Bouncy Castle MLS and schedule upgrade to 1.86
  • Add an independent credential-admission check for external commits until the library is updated
  • Review logging around KeyPackage and LeafNode validation to detect anomalous credential submissions

The record

In Bouncy Castle for Java before 1.86, the Messaging Layer Security (MLS, RFC 9420) implementation did not bind an X.509 credential to a LeafNode's signature_key. LeafNode.verify() checked a leaf's signature against the signature_key carried in the leaf itself, while the credential's X.509 certificate chain was stored but never parsed or validated, so the end-entity certificate's public key was never required to match signature_key as RFC 9420 sec. 5.3 requires. A party could therefore present another party's certificate as its credential while signing the leaf, and the enclosing KeyPackage, with an unrelated key, and be accepted under that other party's identity through KeyPackage.verify() and the Group leaf-validation path. In a deployment that admits external commits without an independent credential-admission check, an unauthenticated attacker could be admitted under a victim's X.509 identity, evict the victim (resynchronization compares whole credentials rather than signing keys), derive the current epoch, decrypt subsequent group messages, and send messages accepted as the victim. TreeKEM.LeafNode now requires the end-entity certificate's subject public key, in the cipher suite's signature encoding, to equal signature_key for an X.509 credential and rejects the leaf otherwise, including an empty chain or a certificate whose key type does not match the cipher suite; certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities