Bouncy Castle CVE-2026-97873

The target must be a Java application using Bouncy Castle (bc-java before 1.86 or bc-lts-java before 2.73.13) as its JCA provider AND must parse or decrypt attacker-influenced data that carries a PBE iteration count - specifically encoded PKCS12PBEParams or PBEParameter consumed by the PKCS12PBE/PBKDF1 AlgorithmParameters, or any Cipher/Mac/SecretKeyFactory in the legacy PBES1/PKCS#12 PBE families, including the common path of javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypting a PKCS#12 PBE-protected private key. Exploitation is limited by UI:P: the victim application must actually ingest and attempt to process the malicious key material, so a deployment that never handles untrusted keystores/encrypted keys is not exposed. Impact is confined to availability (CPU/time exhaustion); there is no confidentiality or integrity effect.

This is a moderate, availability-only issue, not an urgent priority. The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P, VA:L, all confidentiality/integrity N) correctly frames it as a CPU-exhaustion denial of service with no data compromise, consistent with CWE-770 (unbounded resource allocation) and the description, which states an attacker-controlled iteration count dictates arbitrary key-derivation work. No KEV listing, no POC reference, and no EPSS score are present in the input, so exploitation evidence is absent - status is 'no public exploit identified at time of analysis.' The one tempering signal is UI:P (passive user interaction): exploitation is not fully autonomous network exploitation because the victim application must actually ingest and attempt to decrypt the attacker-supplied PKCS#12/PBE material. The signals are internally consistent (network-reachable but requires the app to process malicious input, impact limited to availability); there is no conflict to flag, though the real-world severity depends heavily on whether a given deployment parses untrusted PKCS#12 / encrypted-private-key material with BC as the JCA provider.

An attacker submits a crafted PKCS#12 bundle or PBE-protected encrypted private key whose encoded PKCS12PBEParams/PBEParameter specifies an enormous iteration count to a Java application that uses Bouncy Castle as its JCA provider (for example a service that imports uploaded keystores or calls EncryptedPrivateKeyInfo.getKeySpec()). Because the legacy PBES1/PKCS#12 PBE derivation accepted the count without bounding it, the application burns arbitrary CPU on key derivation before any verification can fail, exhausting a thread or the host. No public exploit code is identified at time of analysis.