CVE-2026-17507
Bouncycastle Bc-Java 1.73 – 1.86
Raw vector
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:AmberCVSS and EPSS are reproduced from their sources (NVD, FIRST EPSS). Risk Priority is our own derived reading, not an NVD score.
Summary
CVE-2026-17507 is a high-severity Signed to Unsigned Conversion Error (CWE-195) vulnerability in Bouncycastle Bc-Java. Its CVSS base score is 8.7 (High).
Operationally, exploitation aligns with the MITRE ATT&CK technique Data Obfuscation (T1001); ranked at the 26th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-91235
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation can discover conversion errors through static analysis, fuzzing, or targeted unit tests.
Requiring documented development standards and tools can enforce coding rules that prohibit or safely wrap such casts.
Engineering principles can mandate safe integer handling and strong typing to avoid unsafe signed-to-unsigned casts.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure SDLC practices (static analysis, code review, safe-integer standards) directly prevent signed-to-unsigned conversion errors.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Secure development life cycle mandates practices that can catch signed-to-unsigned conversion errors during design and coding.
A.8.26 only requires that security requirements (including resilience against attacks such as buffer overflows or SQL injection) be identified and specified during development or acquisition; it does not itself enforce, implement, or prevent the signed-to-unsigned conversion error from arising or being exploitable.
A.8.27 mandates establishing and applying security engineering principles (e.g. least privilege, security by design, hardening) and design reviews during the SDLC; it does not stop a signed-to-unsigned conversion error from being exploitable if the flawed code is written and deployed.
Secure coding standards directly prohibit unsafe signed-to-unsigned casts and require defensive checks.
Security testing in development can detect conversion-related defects before release.