BC-FJA EUVD-2026-54726

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. For the availability (OOM) impact the limiting factor is load level: low-traffic deployments are unlikely to exhaust the finalizer queue, so the practical DoS risk scales with request volume. For the key-material-lingering concern no load threshold is required - any unfixed deployment on Java 9+ fails to guarantee prompt zeroisation. No special feature flags or non-default configurations are needed; the flaw is intrinsic to how the affected class hierarchy implements zeroisation.

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. The availability risk is more straightforwardly exploitable - an attacker who can drive sustained cryptographic workload through a network-facing BC-FJA application can cause OutOfMemoryError. No EPSS score was provided. There is no CISA KEV listing and no known public proof-of-concept. The real-world priority is highest for Java FIPS compliance deployments (finance, healthcare, government) running on Java 12+ JVMs under network-accessible load; organizations still on Java 8 or Java 11 are not affected by the OOM path, though the key zeroisation design flaw is present in all unfixed versions. The fix is available and well-defined, making this a straightforward patch-and-verify remediation rather than a complex mitigate-in-place situation.

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. Separately, if the attacker also possesses a heap-dump or memory-read primitive (e.g., through a concurrent deserialization vulnerability), the unzeroed key material resident in the queue can be extracted. No public proof-of-concept exists for this scenario.