In the vulnerable Bouncy Castle for Java implementations, password‑based key derivation functions (PBKDF2, scrypt, bcrypt) were invoked with cost parameters copied directly from untrusted input, with no enforcement of upper bounds. The affected entry points include the RFC‑9579 PBMAC1 MAC calculator builders, PKCS#8 and PKCS#12 cost guards, the raw PBKDF2 JCA provider, and the bcrypt round count used when parsing OpenSSH v1 private keys. An attacker who can supply crafted key material or cryptographic parameters can force the library to perform an arbitrarily large number of iterations or allocate an unbounded amount of working memory before it rejects the attempt. This results in a denial‑of‑service due to excessive CPU time, memory pressure, or storage usage, consistent with Weak Capacity Control (CWE‑770).

Bouncy Castle for Java binaries prior to version 1.86, the Long Tail Support release series before 2.73.13, and the Bouncy Castle FIPS for Java (BC‑FJA) before bcpkix‑fips 1.0.13, 2.0.13, or 2.1.13. These include the standard Java provider libraries (BC‑JAVA, BC‑LTS‑JAVA) and the FIPS provider modules.

The CVSS score of 5.3 indicates moderate overall severity, and the EPSS score is not available, suggesting limited public data on exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The most likely attack surface is user‑supplied cryptographic files that are parsed by libraries such as PKCS#8, PKCS#12, or OpenSSH v1 private keys. An attacker can trigger the unbounded cost calculations locally by providing a malicious file, or remotely if the application processes client‑supplied key data. Because the flaw requires no privileged execution or code injection, its primary impact is resource exhaustion rather than confidentiality or integrity compromise.