CVE-2026-71890: 
Bouncy Castle vulnerability analysis and mitigation

CVE-2026-71890 is an authorization bypass vulnerability in Bouncy Castle for Java's MLS (Messaging Layer Security, RFC 9420) implementation that allows any party holding a group's public GroupInfo to evict arbitrary members from an MLS group via a crafted external commit. It affects the bcmls component of Bouncy Castle for Java versions 1.73 through 1.85 (fixed in 1.86). The vulnerability was disclosed on October 3, 2026, and was credited to Yu Bao from the PayPal Cyber Security Team. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, bc-java Wiki).

The root cause is CWE-863 (Incorrect Authorization) in the org.bouncycastle.mls.protocol.Group.validateExternalCachedProposals method. RFC 9420 sec. 12.2 permits at most one Remove proposal in an external commit, intended only for a joiner removing their own prior leaf (a "resync" commit), and requires that the joiner's new LeafNode credential be acceptable for the removed participant. However, the validation logic only counted proposals by type and bounded the removed leaf index — it never verified that the removed leaf's credential matched the joiner's own new leaf credential. The ordinary validateRemove self-remove rule was deliberately skipped on this path (correctly, for resync commits), but no equivalent ownership check was substituted. A credential comparison did exist, but only in the gRPC interop harness (MLSClientImpl.externalJoinImpl), leaving the public Group.externalJoin and Group.handle APIs entirely unprotected (bc-java Wiki, Patch Commit).

Any party with access to a group's public GroupInfo — which is precisely what external joiners are meant to receive — can craft an external commit carrying a Remove proposal naming any member's LeafIndex. Every group member will apply the commit, evicting the targeted member and allowing the attacker to take over that member's slot in the ratchet tree. The primary impact is a high-integrity violation: unauthorized modification of group membership state, with no confidentiality or availability impact to the vulnerable system itself. In MLS-based secure messaging or collaboration applications, this could enable an attacker to silently remove legitimate participants from encrypted group sessions, potentially disrupting secure communications or enabling subsequent attacks on group key material (GitHub Advisory, bc-java Wiki).

The vulnerability requires no authentication, no privileges, and no user interaction — only possession of the group's public GroupInfo and knowledge of the target member's LeafIndex (which is visible in the group's ratchet tree). As of the disclosure date, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Obtain GroupInfo: Acquire the target MLS group's public GroupInfo document, which applications using external join are expected to distribute to prospective joiners.
2. Identify target LeafIndex: Inspect the group's ratchet tree (available from the GroupInfo or group state) to enumerate member LeafIndex values and select a victim member to evict.
3. Craft malicious external commit: Construct an external commit using the Group.externalJoin API (or equivalent wire-level message) that includes an ExternalInit proposal and a Remove proposal naming the victim's LeafIndex — without ensuring the joiner's new leaf credential matches the removed leaf's credential.
4. Submit the commit: Send the crafted external commit to the group's delivery service or directly to group members via the Group.handle API path.
5. Achieve member eviction: Because validateExternalCachedProposals does not verify credential identity between the joiner and the removed leaf, every group member processes and applies the Remove proposal, evicting the victim and installing the attacker's leaf in the freed slot (bc-java Wiki, Patch Commit).

The fix is available in Bouncy Castle for Java version 1.86, introduced in commit 7e8bb10eb90b. The patch enforces that an external commit's Remove proposal is accepted only when the removed leaf's credential is byte-for-byte identical to the joiner's own new leaf credential, enforced on both the sending and receiving side. Organizations unable to upgrade immediately should restrict which parties are permitted to perform external joins to MLS groups and implement additional application-level validation of Remove proposals in external commits. Upgrading to version 1.86 or later is the recommended remediation (bc-java Wiki, Patch Commit).

The vulnerability was credited to Yu Bao from the PayPal Cyber Security Team, indicating responsible disclosure through a corporate security research channel. The Bouncy Castle maintainers (Legion of the Bouncy Castle Inc.) published a detailed wiki advisory and patch commit promptly at the time of disclosure. No significant broader media coverage or notable community commentary beyond the official advisory has been identified at this time (bc-java Wiki).