Legion of the Bouncy Castle BC-JAVA up to 1.85 Messaging Layer Security LeafNode.verify certificate validation

Summaryinfo

A vulnerability, which was classified as problematic, has been found in Legion of the Bouncy Castle BC-JAVA up to 1.85. Affected by this issue is the function LeafNode.verify of the component Messaging Layer Security. Performing a manipulation results in certificate validation. This vulnerability is reported as CVE-2026-71885. The attack is possible to be carried out remotely. No exploit exists. It is advisable to upgrade the affected component.

Detailsinfo

A vulnerability, which was classified as problematic, was found in Legion of the Bouncy Castle BC-JAVA up to 1.85. This affects the function LeafNode.verify of the component Messaging Layer Security. The manipulation with an unknown input leads to a certificate validation vulnerability. CWE is classifying the issue as CWE-295. The product does not validate, or incorrectly validates, a certificate. This is going to have an impact on integrity. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is uniquely identified as CVE-2026-71885 since 08/08/2026. The exploitability is told to be difficult. It is possible to initiate the attack remotely. No form of authentication is needed for exploitation. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/03/2026). MITRE ATT&CK project uses the attack technique T1587.003 for this issue.

Upgrading to version 1.86 eliminates this vulnerability.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Productinfo

Type

• Programming Language Software

Vendor

• Legion of the Bouncy Castle

Name

• BC-JAVA

Version

• 1.0
• 1.1
• 1.2
• 1.3
• 1.4
• 1.5
• 1.6
• 1.7
• 1.8
• 1.9
• 1.10
• 1.11
• 1.12
• 1.13
• 1.14
• 1.15
• 1.16
• 1.17
• 1.18
• 1.19
• 1.20
• 1.21
• 1.22
• 1.23
• 1.24
• 1.25
• 1.26
• 1.27
• 1.28
• 1.29
• 1.30
• 1.31
• 1.32
• 1.33
• 1.34
• 1.35
• 1.36
• 1.37
• 1.38
• 1.39
• 1.40
• 1.41
• 1.42
• 1.43
• 1.44
• 1.45
• 1.46
• 1.47
• 1.48
• 1.49
• 1.50
• 1.51
• 1.52
• 1.53
• 1.54
• 1.55
• 1.56
• 1.57
• 1.58
• 1.59
• 1.60
• 1.61
• 1.62
• 1.63
• 1.64
• 1.65
• 1.66
• 1.67
• 1.68
• 1.69
• 1.70
• 1.71
• 1.72
• 1.73
• 1.74
• 1.75
• 1.76
• 1.77
• 1.78
• 1.79
• 1.80
• 1.81
• 1.82
• 1.83
• 1.84
• 1.85

CPE 2.3info

• 🔒
• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Discussion