CVE-2026-58063

If your Java application loads BCFKS keystores, this CVE demands immediate attention — not because the CVSS 5.3 suggests critical severity, but because the exposure lives exactly where you likely handle untrusted input: backup ingestion, key management utilities, multi-tenant services, or anywhere a user or external system can provide a keystore file. The vulnerability is straightforward. The BCFKS keystore format embeds KDF (Key Derivation Function) parameters — specifically iteration counts — directly in the file. When Bouncy Castle loads a keystore, it honors whatever iteration count the file specifies without imposing any upper bound. A malicious keystore can declare an iteration count so large that loading it consumes all available CPU, causing the JVM to hang regardless of whether you provide the correct password. The attack surface is keystore loading itself; the password is irrelevant. Check your dependency tree. Versions before 1.85 and all 2.73.x versions before 2.73.12 are vulnerable. If you ship Bouncy Castle as a transitive dependency — common in enterprise Java — you may be pulling in an affected version without explicit declaration. Run `mvn dependency:tree` or your build tool's equivalent to confirm. The fix in 2.73.12 imposes artificial bounds on KDF parameters, rejecting keystores that specify iteration counts beyond sane computational limits. This is the correct remediation, but be aware that if you have legitimate keystores with unusually high iteration counts (a rare but possible configuration), they will fail to load after the patch. Verify your keystore generation processes to ensure they stay within the new bounds. More importantly, treat any keystore loaded from an untrusted source as a potential denial-of-service vector. If your application accepts keystores from customers, external backups, or cross-system transfers, wrap keystore loading in a timeout mechanism and consider validating iteration counts against documented safe thresholds before attempting load. The abstraction that makes keystores convenient also makes them invisible attack surface — the operation looks like safe credential retrieval but is actually executing arbitrary computational directives from an untrusted file.

Reviewed through automated stages and approved by a human before publication.