CVE-2026-97873: Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider
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.maxiterationcount 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.
Affected Software
Event History
Frequently Asked Questions
Which deployments are realistically exposed to this issue?
Deployments using Bouncy Castle for Java before 1.86, or the Bouncy Castle for Java LTS line before 2.73.13, are affected when they process attacker-controlled legacy PBES1 or PKCS#12 PBE parameters or encrypted material. This includes flows where BC derives keys using parameters decoded by another provider, such as decrypting a PKCS#12 PBE-protected private key through EncryptedPrivateKeyInfo.getKeySpec().
What does an attacker need to supply to trigger the excessive work?
An attacker needs to provide encoded PKCS12PBEParams or PBEParameter data containing a chosen iteration count, or cause a Cipher, Mac, or SecretKeyFactory in an affected PBE family to derive with such a count. A small input can request an arbitrarily large amount of derivation work before the password or encrypted data can be verified.
Are default settings affected after upgrading?
The corrected versions enforce org.bouncycastle.pbe.max_iteration_count, whose default is 10,000,000. They reject negative or over-limit iteration counts during both parameter parsing and key derivation, and reject encoded counts beyond the int range rather than narrowing them.
What mitigation is available if an immediate upgrade is not possible?
Set org.bouncycastle.pbe.max_iteration_count to an appropriate bounded value to limit accepted iteration counts. The described enforcement of this property is in the corrected versions; deployments should also avoid processing untrusted legacy PBES1 and PKCS#12 PBE inputs where possible.