{"items":[{"id":"NVI-00014184","kind":"vulnerability","title":"Bouncy Castle: Zeroisation of sensitive key material on garbage collection relies on finalization.","revision":2,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected.","NVD lastModified does not establish freshness of every associated CPE record."],"lifecycle":"active","identifiers":["GHSA-98j2-6v39-78w8","CVE-2026-13505"],"plain_summary":"GitHub lists this reviewed advisory for org.bouncycastle:bc-fips, org.bouncycastle:bc-fips, org.bouncycastle:bc-fips. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-290578205ae3db5038f4d59778eb6276"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[{"kind":"CVSS","as_of":"2026-10-23T20:10:00.160Z","value":"8.7 HIGH (4.0)","meaning":"91579145-5d7b-4cc5-b925-a0262ff19630 severity; no combined Null risk score.","source_id":"sr-290578205ae3db5038f4d59778eb6276"}],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-567991656ed52ddcd51e4a77432d6bb1","url":"https://github.com/advisories/GHSA-98j2-6v39-78w8","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-98j2-6v39-78w8","publisher":"GitHub Advisory Database","observed_at":"2026-11-01T14:29:31.527Z"},{"id":"sr-290578205ae3db5038f4d59778eb6276","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-13505","basis":"official_catalog","notes":"This product uses data from the NVD API but is not endorsed or certified by the NVD.","title":"CVE-2026-13505","publisher":"NIST National Vulnerability Database","observed_at":"2026-11-07T13:57:03.791Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":["< 1.0.2.7"]},{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":[">= 2.0.0, < 2.0.2"]},{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":[">= 2.1.0, < 2.1.3"]}],"null_published_at":"2026-11-07T18:43:12.078Z","source_updated_at":"2026-09-18T17:37:32.000Z","source_disclosed_at":"2026-08-08T03:31:12.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"Source facts changed; compare the preserved prior revision.","null_first_observed_at":"2026-11-01T14:29:31.527Z"},{"id":"NVI-00014184","kind":"vulnerability","title":"Bouncy Castle: Zeroisation of sensitive key material on garbage collection relies on finalization.","revision":1,"unknowns":["Customer inventory, deployment, reachability and exploitation have not been inspected."],"lifecycle":"active","identifiers":["GHSA-98j2-6v39-78w8","CVE-2026-13505"],"plain_summary":"GitHub lists this reviewed advisory for org.bouncycastle:bc-fips, org.bouncycastle:bc-fips, org.bouncycastle:bc-fips. Published version ranges and source prerequisites are shown below; this is not an inspection of a visitor’s application.","review_status":"source_listed","control_topics":[],"public_actions":[{"summary":"Identify the exact component and deployed version, examine the linked publisher’s conditions, and retain evidence of any mitigation.","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"action_type":"investigate","limitations":"Confirm current vendor support, compatibility and deployment evidence. This report has not tested a fix in your system.","current_supported_target":null}],"schema_version":"1.1.0","source_metrics":[],"why_it_matters":"Published affected context helps an owner decide what evidence to gather. This report has not examined your application.","related_sources":[{"id":"sr-567991656ed52ddcd51e4a77432d6bb1","url":"https://github.com/advisories/GHSA-98j2-6v39-78w8","basis":"vendor_advisory","notes":"GitHub Advisory Database; CC-BY-4.0. Each advisory links its original attribution. Null normalizes fields.","title":"GHSA-98j2-6v39-78w8","publisher":"GitHub Advisory Database","observed_at":"2026-11-01T14:29:31.527Z"}],"affected_context":[{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":["< 1.0.2.7"]},{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":[">= 2.0.0, < 2.0.2"]},{"certainty":"source_listed","source_ids":["sr-567991656ed52ddcd51e4a77432d6bb1"],"technology":"org.bouncycastle:bc-fips","known_exclusions":[],"conditions_summary":"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 f","public_affected_ranges":[">= 2.1.0, < 2.1.3"]}],"null_published_at":"2026-11-02T10:00:37.221Z","source_updated_at":"2026-09-18T17:37:32.000Z","source_disclosed_at":"2026-08-08T03:31:12.000Z","is_synthetic_fixture":false,"null_last_reviewed_at":null,"public_change_summary":"First indexed by Null; source disclosure date is shown separately.","null_first_observed_at":"2026-11-01T14:29:31.527Z"}],"next_cursor":null,"snapshot_revision":"42594"}