IT SBIT Services
Schneeberger
DEEN
CVE tracker

Bouncy Castle BC-JAVA: Denial of service in MLS membership check

CVE-2026-17507High 8.7

← All vulnerabilities

Summary

The MLS module of Bouncy Castle for Java compares a uint32 leaf index as a signed value, so an out-of-range sender passes the membership check. A current member of an MLS group can send one small crafted message that makes the JVM grow a node list until it runs out of heap, which denies service to the other group members. The flaw applies only where the MLS module is used.

Affected

  • Bouncy Castle for Java (bc-java) from 1.73 up to, but excluding, 1.86
  • Versions before 1.73: Unknown.
  • Only applications that use the org.bouncycastle.mls module are affected.

Fixed in

  • Fixed in bc-java 1.86 (fix commit 1eb83471eb01727bfdb944a5a46355cc77d55f44).
  • Exact patched versions of distribution packages: Unknown. Check the vendor or distribution package channel.

Workaround

  • No vendor workaround known.
  • If the MLS module is not used, remove it from the classpath.
  • If MLS is used and upgrading is delayed, restrict MLS message handling to trusted group members and monitor JVM heap usage for OutOfMemoryError events.

Exploitation

  • CISA SSVC: exploitation none, automatable yes, technical impact partial.
  • No evidence of exploitation in the wild found.
  • No public proof of concept found.
  • EPSS is low (about 0.003 to 0.004 in the listings checked).

Our recommendation

  • Inventory Java applications for bc-java versions 1.73 to 1.85 and check whether they use MLS (for example bcmls artifacts in Maven or Gradle dependency trees).
  • Upgrade to bc-java 1.86 or later where MLS is used, and prioritise internet-facing services.
  • Where MLS is not used, confirm that it is not on the classpath or document the risk acceptance.
  • Monitor JVM heap usage after patching.

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 1 Nov 2026, 06:11.

Original description (NVD)

In Bouncy Castle for Java before 1.86, the MLS implementation (org.bouncycastle.mls) holds RFC 9420's uint32 leaf_index in a signed int, so a wire value with the top bit set decodes to a negative number. That is a legitimate encoding rather than malformed input, and it must still decode, since the MLS interop test vectors round-trip the full range. GroupKeySet.SecretTree.hasLeaf and Group.validateRemove compared the decoded value directly against the tree's leaf count, and a signed comparison treats any negative int as less than a positive bound, so an out-of-range sender passed the membership check. In the hasLeaf case the SenderData of an unprotected PrivateMessage could then drive LeafIndex.directPath through NodeIndex.parent() arithmetic that never reaches the tree root, growing the resulting node list without bound until the JVM exhausted its heap. A single small message from any current group member could therefore deny service to every other member of the group. Both comparisons now interpret the value as unsigned via Integer.toUnsignedLong, rejecting an out-of-range sender however it was encoded; well-formed leaf indices are unaffected.

NVD references (2)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.

Get in touchRSS feed