CVE-2026-71885 in BC-JAVA
Summary
by MITRE • 10/03/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java prior to version 1.86 represents a critical failure in cryptographic binding within the implementation of the Messaging Layer Security protocol, defined by RFC 9420. The core technical flaw lies in the verification logic of the LeafNode structure, specifically regarding how X.509 credentials are associated with signing keys. According to the MLS specification section 5.3, a leaf node's signature key must be cryptographically bound to the public key contained within its attached X.509 certificate chain. In the affected implementation, the verification process only checked that the digital signature on the LeafNode matched the signature_key field present directly inside the LeafNode structure itself. Crucially, while the application stored the full X.509 certificate chain associated with the leaf, this data was never parsed or validated against the signing key. This omission meant there was no enforcement requiring the public key extracted from the end-entity certificate to match the signature_key used for verification. Consequently, the protocol failed to ensure that the identity asserted by the credential actually corresponded to the private key capable of generating valid signatures, breaking a fundamental security invariant required for authenticated communication.
The operational impact of this flaw is severe, as it allows an attacker to perform identity spoofing and impersonation attacks within MLS groups. An unauthenticated adversary could construct a malicious LeafNode where the signature_key does not match their own private key but instead corresponds to another user's public key found in that victim's X.509 certificate. By signing this leaf with their own unrelated private key, or potentially exploiting other weaknesses if they can forge signatures, the attacker presents a credential chain belonging to a legitimate party while using an independent key for actual operations. When KeyPackage.verify() and subsequent group leaf-validation paths process this data, they accept the signature against the embedded signature_key without verifying that this key matches the certificate's public key. In deployments that permit external commits without implementing additional application-level checks to validate credential ownership, an attacker can successfully join a group under the victim's X.509 identity. This effectively bypasses authentication mechanisms designed to ensure that only the holder of the private key associated with a specific certificate can act as that entity.
Once admitted into the group under the victim's identity, the attacker gains significant control over the communication channel and the ability to disrupt service for the legitimate user. The MLS protocol uses resynchronization procedures that compare whole credentials rather than just signing keys to determine membership conflicts. Because the attacker presents a valid credential chain matching the victim's identity but signs with a different key, the system may fail to detect this discrepancy during standard conflict resolution, or more likely, allow the attacker to evict the legitimate victim from the group by establishing dominance through their forged leaf node. Upon successful eviction and resynchronization, the attacker derives the current epoch keys for the group cipher suite. This grants them full decryption capabilities for all subsequent messages sent within that epoch, effectively compromising the confidentiality of the entire conversation. Furthermore, because the group accepts messages signed with the victim's identity key pair (which the attacker now controls via their forged leaf), any message posted by the attacker is cryptographically verified as coming from the legitimate user, enabling undetectable impersonation and potential social engineering attacks based on trusted identities.
The remediation for this vulnerability involves a strict enforcement of cryptographic binding between credentials and signing keys in the TreeKEM.LeafNode verification logic. The updated implementation now mandates that when an X.509 credential is present, the end-entity certificate's subject public key must exactly match the signature_key field after applying the cipher suite's specific signature encoding rules. If this equality check fails, or if the certificate chain is empty or contains a certificate with a key type incompatible with the active cipher suite, the leaf node is rejected outright during validation. This change ensures that only parties possessing the private key corresponding to their presented X.509 certificate can successfully participate in group operations under that identity. It is important to note that while this fix addresses the binding issue within the MLS library itself, RFC 9420 section 5.3.1 explicitly states that full certificate-chain validation and final identity verification against a trust anchor remain the responsibility of the application layer. Therefore, developers must ensure their applications also implement robust PKI validation to prevent other forms of credential misuse, although this specific vulnerability is resolved by the library update. Deployments utilizing only basic credentials without X.509 certificates are not affected by this flaw and do not require immediate patching for this specific issue.
From a classification perspective, this vulnerability aligns with CWE-294, which describes authentication bypass through capture-replay attacks or similar mechanisms where identity is decoupled from cryptographic proof of possession. It also relates to CWE-319, the use of a cleartext protocol for transmission of sensitive information, insofar as it allows an attacker to masquerade as another user without detection. In terms of MITRE ATT&CK mapping, this flaw facilitates T1078, Valid Accounts, by allowing attackers to obtain and misuse legitimate credentials or identities within the system context. The attack vector leverages T1556, Modification of Client/Server Authentication Mechanisms, specifically through manipulation of cryptographic bindings in a custom protocol implementation. Security practitioners should prioritize updating Bouncy Castle libraries to version 1.86 or later immediately if their systems rely on MLS with X.509 credentials for authentication and integrity assurance. Additionally, application-level defenses such as explicit credential binding checks during group join operations provide an additional layer of defense in depth against similar implementation flaws that might exist in other MLS stacks.