Legion of the Bouncy Castle Bouncy Castle Java up to 1.85 Mls Leaf Index leaf_index integer overflow

Summaryinfo

A vulnerability was found in Legion of the Bouncy Castle Bouncy Castle Java up to 1.85. It has been classified as problematic. Affected is the function GroupKeySet.SecretTree.hasLeaf/Group.validateRemove of the component Mls Leaf Index Handler. This manipulation of the argument leaf_index causes integer overflow. This vulnerability is registered as CVE-2026-17507. Remote exploitation of the attack is possible. No exploit is available. Upgrading the affected component is recommended.

Detailsinfo

A vulnerability has been found in Legion of the Bouncy Castle Bouncy Castle Java up to 1.85 and classified as problematic. Affected by this vulnerability is the function GroupKeySet.SecretTree.hasLeaf/Group.validateRemove of the component Mls Leaf Index Handler. The manipulation of the argument leaf_index with an unknown input leads to a integer overflow vulnerability. The CWE definition for the vulnerability is CWE-190. The product performs a calculation that can produce an integer overflow or wraparound, when the logic assumes that the resulting value will always be larger than the original value. This can introduce other weaknesses when the calculation is used for resource management or execution control. As an impact it is known to affect availability. The summary by CVE is:

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.

The advisory is shared at github.com. This vulnerability is known as CVE-2026-17507 since 07/27/2026. The exploitation appears to be easy. The attack can be launched remotely. Technical details are known, but no exploit is available.

Upgrading to version 1.86 eliminates this vulnerability.

The vulnerability is also documented in the vulnerability database at CERT Bund (WID-SEC-2026-3713). If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Affected

• Open Source Bouncy Castle

Productinfo

Type

• Programming Language Software

Vendor

• Legion of the Bouncy Castle

Name

• Bouncy Castle 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

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion