If you deploy Bouncy Castle FIPS in a FIPS 140-2/140-3 compliant environment, you need to know this: the key zeroization mechanism that passed certification no longer works as intended on any JVM version that isn't Java 8 or 11.
The vulnerability lives in how BC-FIPS implemented the FIPS "zeroize on disposal" requirement. The library used Object.finalize() to overwrite cryptographic key material when objects were garbage collected. This satisfied the letter of the FIPS requirement at validation time. But finalization was always non-deterministic — it runs at an unspecified time in an unspecified order — and on modern JVMs (Java 9+), the finalizer thread can fall arbitrarily behind allocation rate under load. Under memory pressure, sensitive key material can persist in the heap for minutes or longer than the seconds the compliance requirement assumes.
The patch uses the Cleaner API in a multi-release JAR — the same artifact contains both the original finalize()-based code for Java 8 compatibility and a Cleaner-based implementation for Java 9+. This fixes the vulnerability on newer JVMs but introduces a testing burden: you must validate that the Cleaner path behaves identically to what the finalize path was supposed to do under every edge condition the standard actually required.
Three things you should do now. First, identify which JVM version your Bouncy Castle FIPS deployment runs on — if it's Java 8 or 11, you remain vulnerable despite any library version upgrade, because the old finalization code path is still compiled into the artifact. Second, if your compliance environment permits JVM upgrades, move to Java 17+ to receive the Cleaner-based fix. Third, audit your deployment fleet for the silent divergence problem: organizations that certified their modules on Java 8 and upgraded to Java 17 without re-validation are now running code whose security properties changed without any change to the artifact itself.
This CVE likely documents a pattern that exists in other security-sensitive libraries. Finalization-based cleanup of sensitive material was flagged as problematic in the Java security community by 2006-2008. If Bouncy Castle FIPS made this error, other FIPS-validated modules almost certainly did too. The FIPS 140-2/140-3 validation regime tests cryptographic correctness against a specific runtime snapshot — it has no mechanism to detect when platform behavior drift invalidates static security claims. Treat this CVE as a forcing function to audit other Java security libraries for the same finalize()-based cleanup pattern.