CVE‐2026‐97873

Title: Legacy PBES1 and PKCS#12 PBE iteration count honoured unbounded in the raw JCA provider.

Issue affecting: BC before 1.86, BC-LTS before 2.73.13.

Fixed versions: BC 1.86, BC-LTS 2.73.13.

Platform affected: Java 8 and later.

A password-based KDF is run before anything about the input has been authenticated, so where its iteration count is read from the same untrusted structure a small input dictates an arbitrary amount of work, whether or not the password is right. BC 1.85 bounded the raw JCA PBKDF2 provider on exactly this reasoning (CVE-2026-17508); the legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families beside it in the provider were left unbounded.

Parameter parsing. The AlgorithmParameters implementations for these families — PKCS12PBE and its object identifier aliases such as 1.2.840.113549.1.12.1.3 (pbeWithSHAAnd3-KeyTripleDES-CBC), and PBKDF1 — accepted any iteration count from an encoded PKCS12PBEParams or PBEParameter, and narrowed a value beyond the int range with intValue(), so a wire count of 2^32 arrived as 0.

Derivation. Every Cipher, Mac and SecretKeyFactory in these families derived its key with whatever count it was given. That includes a count decoded by another provider: when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec(key, "BC") decrypts a PKCS#12 PBE-protected private key, the JDK's own provider can decode the parameters and BC's Cipher receives only the resulting PBEParameterSpec, so a bound in the parameter parser alone would not have been reached. The schemes are unauthenticated, so there is nothing to verify first: a 52 byte encrypted key carrying the maximum count held one getKeySpec call for about twenty minutes of CPU.

Both the parameter parse and the derivations now reject a negative or over-limit count, under the same org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that bounds PBKDF2, and the parse also rejects a count beyond the int range rather than narrowing it. Inputs with sane iteration counts are unaffected. The PKCS#12 key store derives through the same provider code, so a deployment that has raised org.bouncycastle.pkcs12.max_it_count above 10,000,000 needs org.bouncycastle.pbe.max_iteration_count raised with it.

The PKCS#8 decryptors in the PKIX API (JcePKCSPBEInputDecryptorProviderBuilder) and the provider's PKCS#12 key store already bounded these counts and were not affected.

The fix was introduced in commit 766a31026a.

Credit: Arpan Sharma.