In Bouncy Castle for Java prior to version 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 signatures against the signature_key in the leaf itself but did not parse or validate the certificate chain, allowing an attacker to present a certificate belonging to another party while signing with an unrelated key. This flaw enables an unauthenticated attacker, in deployments that allow external commits without independent credential checks, to impersonate a victim's X.509 identity, evict the victim from the group, derive the current epoch, decrypt subsequent messages, and send messages accepted as the victim. The fix in version 1.86 enforces that the certificate's subject public key matches the signature_key and rejects leaves with invalid or empty certificate chains. Certificate chain validation to a trust anchor remains the responsibility of the application as per RFC 9420 section 5.3.1. Deployments using only basic credentials are unaffected.

An unauthenticated attacker can impersonate another party's identity within an MLS group, evict legitimate members, decrypt future group messages, and inject messages accepted as the victim. This compromises confidentiality, integrity, and authentication of group communications in affected deployments that admit external commits without independent credential admission checks.

A fix is available in Bouncy Castle for Java version 1.86 that enforces proper binding of the X.509 certificate's public key to the LeafNode's signature_key. Users should upgrade to version 1.86 or later. Deployments using only basic credentials are not affected. Certificate chain validation remains the responsibility of the application per RFC 9420. No additional vendor advisory is provided; check the vendor's official resources for updates.