CVE‐2026‐13505

Title: Zeroisation of sensitive key material on garbage collection relies on finalization.

Issue affecting: BC-FJA before bc-fips 1.0.2.7, 2.0.2 and 2.1.3.

Fixed versions: BC-FJA bc-fips 1.0.2.7, 2.0.2 and 2.1.3.

Platform affected: Java 9 and later.

Bouncy Castle for Java (bcprov) and Bouncy Castle for Java LTS are not affected: neither implements the finalizer-based zeroisation scheme this issue concerns.

Sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was cleared on garbage collection by overriding Object.finalize.

Finalization runs at an unspecified time and in an unspecified order, and the JVM services it from a single finalizer thread. Where objects carrying a finalizer are allocated faster than that one thread retires them, the pending-finalization queue grows without bound: disposal falls arbitrarily far behind, which can contribute to an OutOfMemoryError under load, and the key material those objects hold stays resident in the heap for as long as they are queued — the opposite of what the zeroisation is there to achieve. In practice this did not bite on Java 8 or Java 11; it is later JVMs (post Java 13), where finalization has been deprecated and progressively de-emphasised, on which the behaviour becomes a problem.

Disposal now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later the zeroisation of these classes no longer depends on the finalizer being scheduled.

Recovering key material that has lingered in the heap requires local access to the process or to a dump of it, which is what the severity below reflects; for a FIPS module the prompt-zeroisation requirement holds independently of that reachability.