Bouncy Castle CVE-2026-17508

Exploitation requires that the vulnerable application accept and process an attacker-influenced cryptographic structure through one of the specific affected entry points: the RFC 9579 PBMAC1 MAC calculator builders (JcePBMac1CalculatorBuilder and PKCS12PBEUtils.createPBMac1Calculator, reached via PKCS12PfxPdu.isMacValid), where the PBKDF2 iteration count and derived-key length come straight from PBMAC1Params; the PKCS#8/PKCS#12 scrypt cost guards, where the parallelization parameter p was unbounded even though scratch memory scales with r*p; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); or the bcrypt round count taken from an encrypted OpenSSH v1 private key's kdfoptions. The limiting factor is that the attacker must get the malicious blob to a code path that performs the derivation (vendor marks UI:P, passive processing of the supplied data), and only affects versions before the patched releases; there is no auth requirement (PR:N) and default configurations are affected since the parameters were read without any bound. Impact is confined to availability - the derivation runs before the password/MAC check, so no key material or data is exposed.

This is a genuine but modest-severity availability issue (CWE-770, uncontrolled resource consumption), not a high-impact priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L) yields 5.3 (Medium) with impact limited strictly to availability (VA:L) - no confidentiality or integrity exposure. The core risk is a pre-authentication CPU/memory denial-of-service: KDF cost parameters (PBKDF2 iteration count and key length, scrypt parallelization p, bcrypt rounds) are read from the untrusted input itself and run before any password or integrity check, so a tiny crafted input can force arbitrary work. No EPSS score was provided; the CVE is not in CISA KEV; and no public exploit was supplied (the GitHub commit includes a regression unit test, which is not a weaponized POC). Signals are therefore consistent and low-to-moderate: a real, patchable weakness in a very widely deployed crypto library, but one that degrades availability rather than enabling compromise, and with no evidence of active exploitation. Note a cross-vector consistency point to verify: the vendor marks UI:P (passive interaction, i.e. the victim application must process attacker-supplied data), yet server-side paths such as PKCS12PfxPdu.isMacValid or CMP PBMAC1 verification may run with no user interaction at all - real-world exposure depends on whether the input reaches the parser automatically.

An attacker submits a crafted PKCS#12 PFX, PKCS#8/PBES2 blob, CMP PBMAC1-protected message, or OpenSSH v1 private key in which the embedded KDF cost parameters (e.g. a PBKDF2 iteration count above 10,000,000, or an inflated scrypt p) are set absurdly high. When the vulnerable Bouncy Castle application parses and attempts to verify or decrypt it, the library runs the key derivation with those attacker-dictated parameters before rejecting the wrong password, consuming large amounts of CPU and memory. No public exploit is identified, but the flaw is trivially triggered by hand-editing the cost fields of a sample structure.