CVE-2026-13505: CWE-772 Missing Release of Resource after Effective Lifetime in Legion of the Bouncy Castle Inc. BC-FJA
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was zeroised on garbage collection by overriding Object.finalize. Finalization runs at an unspecified time and in an unspecified order and is serviced by a single finalizer thread, so where objects carrying a finalizer are allocated faster than that 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, defeating the purpose of the zeroisation. The behaviour was not a problem on Java 8 or Java 11; it is later JVMs, on which finalization has been deprecated and progressively de-emphasised, where it becomes one. Disposal of these classes now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later it no longer depends on the finalizer being scheduled. Bouncy Castle for Java (bcprov) and Bouncy Castle for Java LTS are not affected, as neither implements the finalizer-based zeroisation scheme.
AI Analysis
Technical Summary
The vulnerability arises because BC-FJA versions prior to 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series), and 2.1.3 (2.1.X series) zeroise sensitive key material only during object finalization via overriding Object.finalize. Since finalization timing is unspecified and handled by a single thread, objects with finalizers can accumulate, delaying zeroisation and causing key material to remain in heap memory longer than intended. This behavior is problematic on Java 9 and later JVMs where finalization is deprecated and less reliably scheduled, potentially leading to OutOfMemoryError and defeating zeroisation goals. The fix involves switching to java.lang.ref.Cleaner for disposal, which operates independently of finalization scheduling. Bouncy Castle for Java (bcprov) and its LTS variant are not affected as they do not use finalizer-based zeroisation.
Potential Impact
Sensitive cryptographic key material may remain in memory longer than intended, increasing the risk of exposure through memory inspection or other memory disclosure vulnerabilities. Additionally, under load, the accumulation of objects awaiting finalization can cause memory pressure and potentially lead to OutOfMemoryError conditions. This undermines the security guarantees of zeroisation and may compromise cryptographic operations relying on timely key material disposal.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor has addressed the issue in versions 1.0.2.7, 2.0.2, and 2.1.3 by replacing finalizer-based zeroisation with java.lang.ref.Cleaner-based disposal. Users should upgrade to these fixed versions when available. No other mitigation steps are specified.
CVE-2026-13505: CWE-772 Missing Release of Resource after Effective Lifetime in Legion of the Bouncy Castle Inc. BC-FJA
Description
In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series) and 2.1.3 (2.1.X series), sensitive key material held by the AES and DESede engines, the SP 800-90A DRBGs, SymmetricSecretKey and the PBKD and scrypt parameter classes was zeroised on garbage collection by overriding Object.finalize. Finalization runs at an unspecified time and in an unspecified order and is serviced by a single finalizer thread, so where objects carrying a finalizer are allocated faster than that 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, defeating the purpose of the zeroisation. The behaviour was not a problem on Java 8 or Java 11; it is later JVMs, on which finalization has been deprecated and progressively de-emphasised, where it becomes one. Disposal of these classes now runs from a java.lang.ref.Cleaner registered in the multi-release jdk1.9 overlay, so on Java 9 and later it no longer depends on the finalizer being scheduled. Bouncy Castle for Java (bcprov) and Bouncy Castle for Java LTS are not affected, as neither implements the finalizer-based zeroisation scheme.
CVSS v4.0
Score 8.7high
Affected software
Legion of the Bouncy Castle Inc.
BC-FJA
pkg:maven/org.bouncycastle/bc-fipsRun on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
The vulnerability arises because BC-FJA versions prior to 1.0.2.7 (1.0.X series), 2.0.2 (2.0.X series), and 2.1.3 (2.1.X series) zeroise sensitive key material only during object finalization via overriding Object.finalize. Since finalization timing is unspecified and handled by a single thread, objects with finalizers can accumulate, delaying zeroisation and causing key material to remain in heap memory longer than intended. This behavior is problematic on Java 9 and later JVMs where finalization is deprecated and less reliably scheduled, potentially leading to OutOfMemoryError and defeating zeroisation goals. The fix involves switching to java.lang.ref.Cleaner for disposal, which operates independently of finalization scheduling. Bouncy Castle for Java (bcprov) and its LTS variant are not affected as they do not use finalizer-based zeroisation.
Potential Impact
Sensitive cryptographic key material may remain in memory longer than intended, increasing the risk of exposure through memory inspection or other memory disclosure vulnerabilities. Additionally, under load, the accumulation of objects awaiting finalization can cause memory pressure and potentially lead to OutOfMemoryError conditions. This undermines the security guarantees of zeroisation and may compromise cryptographic operations relying on timely key material disposal.
Mitigation Recommendations
Patch status is not yet confirmed — check the vendor advisory for current remediation guidance. The vendor has addressed the issue in versions 1.0.2.7, 2.0.2, and 2.1.3 by replacing finalizer-based zeroisation with java.lang.ref.Cleaner-based disposal. Users should upgrade to these fixed versions when available. No other mitigation steps are specified.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- bcorg
- Date Reserved
- 2026-06-28T01:23:14.833Z
- Cvss Version
- 4.0
- State
- PUBLISHED
Threat ID: 6a7685e1bf8831d539a35fd9
Added to database: 08/08/2026, 01:26:57 UTC
Last enriched: 08/15/2026, 15:13:37 UTC
Last updated: 09/22/2026, 03:52:23 UTC
Views: 98
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.