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.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - 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. (CVE-2026-13505)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - 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. (CVE-2026-13505)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
462931	Echo: org.bouncycastle:bc-fips: security update to 1.0.2.7	Tenable Cloud Security	Echo Local Security Checks	Local	high
462931	Echo: org.bouncycastle:bc-fips: security update to 1.0.2.7	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
334712	Linux Distros Unpatched Vulnerability : CVE-2026-13505	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-13505

high

Tenable Plugins

high

high

high