Bouncy Castle Java: Missing credential binding in MLS X.509 leaf validation
Summary
Bouncy Castle for Java before 1.86 does not verify that the X.509 certificate in an MLS (RFC 9420) credential matches the signature key of the leaf node. An attacker can present another party's certificate and be accepted under that identity. If the application admits external commits without an independent credential check, an unauthenticated attacker can join a group as the victim, evict them, and read and send group messages. Deployments that use only basic credentials are not affected.
Affected
- Bouncy Castle for Java (bcprov, bcpkix) before 1.86, including Java 8 and later
- Relevant only where MLS is used with X.509 credentials
- Not affected: deployments using only basic credentials
Fixed in
- Fixed in Bouncy Castle for Java 1.86
- Fix commit: 77632a57edf350a7b5751fca1a5052daffa8dab2
- Fix status for the BC-LTS branch: Unknown.
Workaround
- If an upgrade is not possible in the short term, stop publishing GroupInfo and ratchet trees for external joining, or add an independent credential-admission check for external commits.
- Certificate-chain validation to a trust anchor remains the application's responsibility.
Exploitation
- CISA SSVC: Exploitation none, Automatable no, Technical Impact total.
- Sources conflict on exploitation; no primary source confirms in-the-wild exploitation.
- No public exploit found in GitHub or Exploit-DB at time of research.
- EPSS 0.19% according to one aggregator.
Our recommendation
- Inventory Java and Android applications for bcprov or bcpkix below 1.86, including transitive dependencies.
- Upgrade to Bouncy Castle 1.86 or later.
- Where MLS is used with X.509 credentials, review group-admission controls and apply an independent credential check for external commits.
- Where MLS is not used, treat the upgrade as routine patching.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Bouncy Castle wiki: CVE-2026-71885 github.com
- Fix commit 77632a57 github.com
- Bouncy Castle 1.86 release announcement www.bouncycastle.org
- OSV: CVE-2026-71885 osv.dev
- DevGuard vulnerability entry docs.devguard.org
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 04:55.
Original description (NVD)
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.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.