In Bouncy Castle for Java versions prior to 1.86, the MLS implementation did not enforce that the X.509 certificate's public key matched the LeafNode's signature_key as required by RFC 9420 section 5.3. The LeafNode.verify() method validated the signature against the signature_key in the leaf but did not parse or validate the certificate chain, allowing an attacker to present a different party's certificate while signing with an unrelated key. This could allow an unauthenticated attacker to be admitted under a victim's X.509 identity in deployments that accept external commits without independent credential checks, leading to victim eviction, decryption of group messages, and message forgery. 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 per RFC 9420 sec. 5.3.1. Deployments using only basic credentials are unaffected.

An unauthenticated attacker could impersonate another party's X.509 identity within an MLS group, evict the legitimate member, decrypt subsequent group messages, and send messages accepted as the victim. This compromises group confidentiality, integrity, and membership authentication in affected deployments that admit external commits without independent credential checks.

A fix is available in Bouncy Castle for Java version 1.86 and later, which enforces that the end-entity certificate's public key matches the LeafNode's signature_key. Users should upgrade to version 1.86 or later. Certificate chain and identity validation remain the responsibility of the application as per RFC 9420. Deployments using only basic credentials are not affected and require no action.