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… (CVE-2026-71885)

In Bouncy Castle for Java before version 1.86, the MLS implementation did not enforce that the X.509 certificate's public key matches the LeafNode's signature_key as required by RFC 9420 section 5.3. The LeafNode.verify() method only checked the signature against the signature_key carried in the leaf, ignoring the certificate chain's public key. This flaw allows an attacker to present another party's certificate with an unrelated key and be accepted as that party's identity in the group. In deployments that allow external commits without independent credential admission checks, an unauthenticated attacker could be admitted under a victim's identity, evict the victim, derive the current epoch, decrypt group messages, and send messages accepted as the victim. The fix requires the LeafNode to reject leaves where the certificate's public key does not match the signature_key, including empty or mismatched certificate chains. Certificate chain validation remains the application's responsibility. Deployments using only basic credentials are unaffected.

An unauthenticated attacker can impersonate another party's X.509 identity within an MLS group, potentially evicting the legitimate member, decrypting subsequent group messages, and injecting messages accepted as the victim. This compromises confidentiality, integrity, and authentication of group communications.

Upgrade to Bouncy Castle for Java version 1.86 or later where the MLS implementation enforces binding between the X.509 certificate's public key and the LeafNode's signature_key. Until then, deployments should ensure independent credential admission checks are in place to prevent unauthorized external commits. Certificate chain and identity validation to trust anchors remain the application's responsibility as per RFC 9420 section 5.3.1.