Bouncy Castle FIPS: CVE-2026-13505 delays key deletion

A high-severity vulnerability in Bouncy Castle FIPS could delay the deletion of sensitive cryptographic keys from Java memory. CVE-2026-13505 affects specific versions of BC-FJA and requires an upgrade, especially for applications running on newer versions of the JVM.

The problem is related to the way the library zeroed out key material during garbage collection. According to the project's official technical announcement, the process relied on the Object.finalize, which does not guarantee when it will be executed.

See also: Bouncy Castle Java: Five new vulnerabilities require immediate upgrade

How CVE-2026-13505 works

The vulnerability affects components that manage key material, including the AES and DESede engines, the SP 800-90A random number generators, the SymmetricSecretKey , and the PBKD and scrypt parameters. When these objects are released, the key remains in memory until a final cleanup is performed.

Java services finalization queues from a single thread. If an application creates objects faster than the thread can remove them, the queue grows and zero-write data is delayed indefinitely. The issue is documented as CWE-772 and the CVE Feed gives it a CVSS score of 8.7.

The delay does not mean that every discarded key is immediately recoverable by a remote attacker. The official description notes that local access to the process or a memory dump is required. However, in high-load environments the queue can contribute to OutOfMemoryError, while the persistence of keys defeats the purpose of zero-deletion.

The issue is of particular importance for services that use BC-FJA as a cryptographic provider in authentication, signing, or data protection applications. In such an environment, early deletion is not just a matter of saving memory, but part of the policy of protecting secrets. The analysis must be combined with the operation of the garbage collector and with the procedures that allow the creation of memory dumps. Particular attention is needed when systems host multiple applications or serve a large number of requests simultaneously, with critical keys in active use today.

See also: Guzzle CVE-2026-69246: Critical vulnerability bypasses host checks

Which versions of Bouncy Castle FIPS are affected?

CVE-2026-13505 affects BC-FJA before bc-fips 1.0.2.7 in the 1.0.X series, before 2.0.2 in the 2.0.X series, and before 2.1.3 in the 2.1.X series. These three versions include the fix and should be used depending on the release line each organization has adopted.

The impact is primarily on Java 9 and newer environments, as finalization has been degraded and is not a reliable timing mechanism. The announcement states that the issue did not manifest itself in the same way in Java 8 and Java 11. At the same time, the regular Bouncy Castle for Java and Bouncy Castle for Java LTS packages are not affected.

The Bouncy Castle FIPS fix

The fix moves the deallocation process to a java.lang.ref.Cleaner, which is registered in the jdk1.9 multi-issue section. Thus, in Java 9 and later, zero-clearing of affected classes no longer depends on whether and when the finalizer is scheduled.

System administrators should identify Maven dependencies that use org.bouncycastle:bc-fips, check the version line, and schedule testing before installation. The upgrade also requires compatibility checks with FIPS requirements, JVM settings, and other application libraries.

After upgrading, it is advisable to review memory dumps, logs, and secret management processes, without keeping unnecessary dump files in shared locations. The SecNews technical team recommends prioritizing installations that process high-value keys or operate under increased load.

See also: Progress Kemp LoadMaster: Critical root command execution vulnerability