CVE-2026-17507 Bouncy Castle Java MLS 整数符号处理漏洞
影响任意群成员可发送单条消息导致其他成员 JVM 堆内存耗尽拒绝服务
Bouncy Castle for Java 1.86 之前的 MLS 实现（org.bouncycastle.mls）将 RFC 9420 的 uint32 leaf_index 存储为有符号 int，导致最高位为 1 的合法编码被解码为负数。GroupKeySet.SecretTree.hasLeaf 和 Group.validateRemove 直接使用有符号比较，使越界发送者通过成员校验。
影响范围
Bouncy Castle for Java 1.86 之前的版本，涉及 org.bouncycastle.mls 的 MLS 实现。
漏洞详情
漏洞类型为整数符号处理不当。MLS 协议中 leaf_index 为无符号 32 位整数，但实现使用有符号 int 存储，最高位为 1 时解码为负数。由于有符号比较中负数总小于正数上界，越界发送者可通过成员检查；在 hasLeaf 场景下，未受保护的 PrivateMessage 的 SenderData 可驱动 LeafIndex.directPath 通过 NodeIndex.parent() 算术不断增长节点列表，直至 JVM 堆耗尽。
利用条件与风险
利用前提是攻击者为当前群组成员，可发送一条小消息即可对群内其他所有成员造成拒绝服务。CVSS 等级为 MEDIUM。
修复建议
升级至 Bouncy Castle for Java 1.86 或更高版本，该版本使用 Integer.toUnsignedLong 进行无符号比较以拒绝越界发送者。暂无其他公开临时缓解措施。
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.