EUVD-2026-54726
GHSA-98j2-6v39-78w8
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber
AV:N and PR:N because load is triggerable via unauthenticated network requests; C:L added over official VC:N to reflect unzeroed key material lingering in heap beyond intended lifetime.
Primary rating from Vendor (bcorg).
CVSS VectorVendor: bcorg
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber
Lifecycle Timeline
3DescriptionCVE.org
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.
Articles & Coverage 1
AnalysisAI
Cryptographic key material in Bouncy Castle for Java FIPS (BC-FJA) persists in the JVM heap far beyond its intended lifetime on Java 12 and later runtimes because the library's zeroisation scheme relies on Object.finalize(), a mechanism progressively de-emphasized since Java 9 and deprecated for removal in Java 18. Under load, the single finalizer thread cannot retire pending objects as fast as they are allocated, causing the queue to grow without bound - resulting in an OutOfMemoryError that crashes the application and defeating the cryptographic hygiene goal of prompt key zeroisation. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | The vulnerability is triggered when: (1) the application uses BC-FJA specifically - not bcprov or BC-LTS; (2) the JVM version is Java 9 or later, with the OutOfMemoryError path most reliably manifesting on Java 12+ where finalization has been de-emphasized and on Java 18+ where it is deprecated for removal; and (3) the rate of BC-FJA cryptographic object allocation exceeds what the single finalizer thread can retire - typically requiring sustained or high-throughput load. … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The provided CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H, score 8.7, Amber urgency) captures the primary availability threat but rates confidentiality impact as none (VC:N), which conflicts with the reporter-assigned 'Information Disclosure' tag and the CVE description's explicit concern that key material 'stays resident in the heap for as long as they are queued, defeating the purpose of the zeroisation.' This discrepancy is worth flagging: the VC:N scoring reflects that no attacker directly reads the key data through this vulnerability alone; a second-step heap access (heap dump, memory forensics, or a separate arbitrary-read primitive) would be needed. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A threat actor targeting a financial services API that uses BC-FJA for FIPS-compliant TLS key operations on a Java 17 JVM sends a sustained high-volume stream of requests that each cause BC-FJA to instantiate and discard AES or DESede engine objects. The single JVM finalizer thread cannot retire the pending-finalization queue fast enough, causing heap exhaustion and an OutOfMemoryError that crashes the API process. … |
| Remediation | Upgrade to one of the patched releases: bc-fips 1.0.2.7 (for the 1.0.X series), 2.0.2 (for the 2.0.X series), or 2.1.3 (for the 2.1.X series). … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours, conduct an inventory of all Java applications and services using Bouncy Castle for Java FIPS (BC-FJA), prioritizing those with network accessibility that handle sensitive encryption keys. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today