CVE-2026-97873 in Bouncy Castle for Java
Summary
by MITRE • 10/03/2026
In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java versions prior to 1.86, including the Long Term Support release before 2.73.13, represents a critical resource exhaustion flaw within the legacy password-based encryption implementations. Specifically, this issue affects the raw JCA provider's handling of PKCS#5 scheme 1 (PBES1) and PKCS#12 Password-Based Encryption families. The core technical deficiency lies in the lack of bounds checking on iteration counts during password-based key derivation processes. In these legacy cryptographic schemes, the number of iterations used to derive encryption keys from passwords is a primary factor determining computational cost. When an application utilizes Bouncy Castle to process encrypted data protected by PBES1 or PKCS#12 PBE algorithms, it relies on parameters extracted directly from untrusted input sources such as encoded certificates, keystores, or serialized cryptographic objects. Prior to the patch, these implementations failed to validate whether the iteration count specified in the ASN.1 structure was reasonable, allowing an attacker to supply a value that would force the system to perform an excessive amount of computational work before any validity check could occur.
From a technical perspective, the flaw manifests through multiple entry points within the cryptographic provider architecture. The AlgorithmParameters implementations for PKCS12PBE and its object identifier aliases, as well as PBKDF1, were designed to accept iteration counts from encoded structures like PKCS12PBEParams or PBEParameter without enforcing upper limits. A significant aspect of this vulnerability involves integer handling during the parsing phase. When decoding these parameters, the implementation utilized intValue() on values that could exceed the range of a signed 32-bit integer. This operation resulted in value narrowing, where large positive integers could be truncated into negative numbers or small positive numbers depending on bit manipulation, but more critically, if not properly bounded before derivation, it allowed for arbitrary control over the workload. Furthermore, every Cipher, Mac, and SecretKeyFactory instance within these families would proceed with key derivation using whatever count was provided in the input structure. This behavior persisted even when parameters were decoded by other providers' AlgorithmParameters implementations, such as during the decryption of a PKCS#12 PBE-protected private key via javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(). Consequently, an attacker could craft maliciously formatted cryptographic material that forces the server or application to consume significant CPU resources and memory for each request.
The operational impact of this vulnerability is severe, primarily categorized as a Denial of Service attack vector. By submitting requests containing encrypted payloads with extremely high iteration counts, an adversary can induce a resource exhaustion condition on the target system. Since password-based key derivation is inherently computationally intensive, amplifying the iteration count exponentially increases processing time and CPU utilization. This does not necessarily require authentication or valid credentials; the mere act of parsing and attempting to derive keys from the malicious input triggers the expensive computation. In high-throughput environments such as web servers handling SSL/TLS handshakes with client certificates protected by PKCS#12, or applications frequently loading encrypted keystores, this vulnerability can lead to rapid service degradation or complete unavailability. The lack of a bounding mechanism means that even a single malicious request can tie up server threads for an extended period, effectively blocking legitimate traffic and degrading the overall availability of the application infrastructure.
To mitigate this risk, organizations must upgrade Bouncy Castle for Java to version 1.86 or later, or if using the Long Term Support branch, to version 2.73.13 or higher. The patch introduces strict validation logic that rejects iteration counts which are negative or exceed a defined maximum limit controlled by the org.bouncycastle.pbe.max_iteration_count property. By default, this threshold is set to ten million iterations, aligning with industry best practices for balancing security strength against performance constraints. This change ensures that any attempt to exploit the vulnerability through excessive iteration counts will result in an immediate rejection of the input rather than triggering a costly computation loop. Additionally, developers should review their cryptographic configurations to ensure they are not relying on legacy PBES1 or PKCS#12 PBE algorithms where possible, as modern standards like PBKDF2 offer more robust and predictable performance characteristics with built-in safeguards against such abuse.
This vulnerability aligns with CWE-787: Out-of-bounds Write in terms of improper validation leading to resource misuse, though it is more accurately described by CWE-400: Uncontrolled Resource Consumption due to the denial of service impact resulting from unbounded iteration counts. In the context of the MITRE ATT&CK framework, this flaw facilitates the T1496: Resource Hijacking technique, where attackers leverage computational resources for disruptive purposes rather than data exfiltration or persistence. The failure to validate input parameters against expected bounds is a classic example of CWE-20: Improper Input Validation, specifically regarding numeric range checks in cryptographic parameter parsing. Addressing this issue requires not only the software update but also rigorous testing of all code paths that interact with encrypted private keys and password-based encryption schemes to ensure no legacy fallback mechanisms bypass the new validation logic.