Bouncy Castle bc-java CVE-2026-71885

Exploitation requires an MLS (RFC 9420) deployment that (1) uses X.509 credentials - deployments using only basic credentials are explicitly unaffected - and (2) admits external commits WITHOUT an independent credential-admission check that binds the presenting party to the credential. Under those conditions an unauthenticated remote attacker can present another party's certificate while signing with an unrelated key and be accepted as that party via KeyPackage.verify() and the Group leaf-validation path. Limiting factors that reduce real-world exposure: the MLS/X.509 code path must be in use (a niche, recently standardized feature), the application must not perform its own credential-admission/trust-anchor validation (certificate-chain and identity validation to a trust anchor remain the application's responsibility per RFC 9420 sec. 5.3.1, and a correct admission check blocks the attack), and the product must be on bc-java before 1.86.

This is a genuine high-priority flaw for the narrow population that uses it, but its real-world blast radius is gated by configuration. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N, VC:H/VI:H/VA:L, score 9.2 Critical) describes a remote, unauthenticated identity-impersonation defect: an attacker can be admitted under a victim's X.509 identity, decrypt the current and subsequent epoch's group messages (VC:H), send messages accepted as the victim and evict them (VI:H), with a limited availability effect from the eviction/resync (VA:L). The AT:P (Attack Requirements: Present) metric is the key honest signal - exploitation is NOT universal; it depends on a deployment that (a) uses X.509 credentials rather than basic credentials and (b) admits external commits without an independent credential-admission check, which the vector correctly reflects rather than inflating to AT:N. No EPSS score was provided, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit code was supplied, so despite the Critical rating there is no evidence of active or opportunistic exploitation - consistent with the fact that the affected code is a newly adopted MLS/RFC 9420 implementation with a small deployment base. CWE-295 (Improper Certificate Validation) matches the root cause precisely: the credential's certificate chain was stored but never checked against signature_key. Net: a real, well-characterized cryptographic authentication bypass that patch-eligible users should fix promptly, but not a widespread, mass-exploitable emergency.

An MLS group using X.509 credentials permits external commits without an independent check that the committing party owns the credential it presents. A remote, unauthenticated attacker crafts a LeafNode/KeyPackage carrying a victim's X.509 certificate as its credential while signing with their own unrelated key; because LeafNode.verify() only checked the self-declared signature_key, the leaf is accepted under the victim's identity. The attacker then evicts the victim, derives the current epoch, and both decrypts subsequent group messages and sends messages accepted as the victim. No public exploit identified at time of analysis.