CVE-2026-17508 in Bouncy Castle for Java
Summary
by MITRE • 10/02/2026
In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Bouncy Castle for Java versions prior to 1.86 represents a critical class of resource exhaustion flaws, specifically categorized under CWE-400: Uncontrolled Resource Consumption. This issue stems from the library's handling of password-based key derivation functions where cost parameters are extracted directly from untrusted input without adequate validation or bounding. In cryptographic operations involving PBKDF2 and scrypt algorithms, computational complexity is typically controlled by iteration counts, memory usage factors, and parallelization coefficients. When these values are derived solely from external data such as encrypted keys or MAC parameters, an attacker can supply maliciously crafted inputs that dictate arbitrarily high resource consumption before any integrity check or password validation occurs. This design flaw allows for efficient denial-of-service attacks where a small input triggers disproportionate CPU or memory usage on the server side.
The specific technical flaws manifest across several distinct code paths within the library. In the context of RFC 9579 PBMAC1 MAC calculator builders, specifically through JcePBMac1CalculatorBuilder and PKCS12PBEUtils.createPBMac1Calculator which is invoked by PKCS12PfxPdu.isMacValid, the iteration count for PBKDF2 and the derived-key length are taken directly from PBMAC1Params. Because these values are not bounded before being passed to the key derivation function, an attacker can specify extremely high iteration counts or large output lengths, forcing the system to perform extensive computational work during the validation phase. This bypasses any pre-checks that might otherwise reject invalid credentials early in the process, thereby maximizing the resource cost per authentication attempt.
A similar vulnerability exists within the PKCS#8 and PKCS#12 cost guards associated with scrypt implementations. While these guards previously implemented limits on the cost parameter N and the block size r, they failed to bound the parallelization parameter p. Since the scratch buffer required by scrypt scales proportionally with the product of r and p, an attacker can evade memory ceilings entirely by setting a low value for r while simultaneously specifying a massive value for p. This allows the exploitation to consume excessive amounts of heap memory without triggering existing limits designed to prevent out-of-memory conditions. The raw JCA PBKDF2 provider located at org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2 also suffered from this lack of parameter bounding, allowing uncontrolled resource consumption during standard Java Cryptography Architecture operations.
Additionally, the vulnerability extends to the handling of encrypted OpenSSH v1 private keys where the bcrypt round count is read directly from the key's own kdfoptions section. By manipulating these options within a maliciously crafted private key file, an attacker can force the decryption process to execute bcrypt with an excessive number of rounds. This results in significant CPU exhaustion on systems attempting to load or verify such keys. The remediation for this specific vector involves bounding the parameter before derivation and introducing a new configurable property, org.bouncycastle.openssh.max_rounds, which allows administrators to set explicit limits on acceptable round counts for OpenSSH key processing.
This issue is part of a broader effort to secure password-based encryption mechanisms within Bouncy Castle, following similar fixes applied in version 1.85 regarding PKCS#8 and PBES2 decryptors as documented under CVE-2026-15055. The attack vector aligns with the ATT&CK technique T1496: Resource Hijacking, where adversaries leverage legitimate software processes to consume excessive system resources for denial-of-service purposes. The vulnerability affects not only the standard Bouncy Castle for Java releases prior to 1.86 but also extends to long-term support versions before 2.73.13 and FIPS-compliant variants including bcpkix-fips series 1.0.X before 1.0.13, 2.0.X before 2.0.13, and 2.1.X before 2.1.13. Organizations utilizing these libraries must upgrade to the patched versions immediately to mitigate the risk of resource exhaustion attacks targeting cryptographic operations involving password-based key derivation.