BC-JAVA: Missing authorization in MLS external commit allows member removal
Summary
Bouncy Castle for Java contains a flaw in the MLS (RFC 9420) external commit handling. An external party that holds the group's public GroupInfo can commit a Remove proposal naming any group member, which evicts that member and lets the attacker take over the freed slot. The issue affects only applications that use the MLS API of the library; it is not exploited in the wild.
Affected
- BC-JAVA from 1.73 up to, but not including, 1.86
- Default configuration is not affected according to the CNA record
Fixed in
- BC-JAVA 1.86
Workaround
- No vendor workaround known.
- If an upgrade is delayed, limit who can obtain the group's public GroupInfo, as the attack depends on it.
Exploitation
- No evidence of exploitation in the wild.
- Not listed in CISA KEV.
- No public proof of concept found.
- CISA SSVC: exploitation none, automatable yes, technical impact partial.
Our recommendation
- Inventory Java applications and dependencies that use Bouncy Castle, including transitive dependencies, and check their versions.
- Find out whether any product uses the MLS API; if none does, the risk is low.
- Upgrade affected components to BC-JAVA 1.86 or a vendor build that contains the fix.
- Limit distribution of GroupInfo until the upgrade is done.
Public exploits
PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.
Research sources
- Vendor CVE page (bc-java wiki) github.com
- Vendor fix commit 7e8bb10 github.com
- Bouncy Castle 1.86 release announcement www.bouncycastle.org
- OSV record CVE-2026-71890 osv.dev
- SUSE CVE record vulners.com
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 1 Nov 2026, 05:42.
Original description (NVD)
In Bouncy Castle for Java before 1.86, validation of an MLS (RFC 9420) external commit's proposal list, org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals, counted the proposals by type and bounded the removed leaf index but never established that the removed leaf had anything to do with the joiner. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, with which the joiner removes an old version of themselves, and requires that where one is present the LeafNode in the commit's path field meet the criteria it would have to meet in an Update for the removed leaf, in particular that its credential present identifiers acceptable for the removed participant. The ordinary proposal-list validator's self-remove rule is deliberately not applied on this path, because a resync commit legitimately removes a leaf the joiner owns, but nothing was put in its place. Any party holding the group's public GroupInfo, which is precisely what an external joiner is meant to be given, could therefore commit a Remove naming any member's LeafIndex and have every member apply it, evicting that member and taking over their slot in the ratchet tree. The credential check that should have prevented this existed only in the gRPC interop harness and so protected no other caller of the public Group.externalJoin and Group.handle API. An external commit carrying a Remove is now accepted only when the removed leaf's credential is identical to the one in the joiner's own new leaf, on both the sending and the receiving side.
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.