BC-FJA EUVD-2026-54725

The vulnerability requires all of the following to be simultaneously true: the application must use bc-fips in the 2.1.x series strictly before version 2.1.3 (bc-fips 1.0.x, bc-fips 2.0.x, and the standard bcprov library are explicitly NOT affected); execution must occur on an Intel x86 platform where the JNI native entropy path is active; and one of three persistent entropy failure conditions must be present - a hardware fault in the on-chip entropy source, extreme DRBG exhaustion from simultaneous entropy requests across many CPU cores, or a hypervisor or VMM that does not forward RDRAND and RDSEED instructions to the guest. The third condition (hypervisor non-forwarding) is the most operationally common and requires no attacker-side action beyond being co-resident on or having network access to the affected VM. Exploitation is strictly limited to denial of service; no code execution, credential theft, or cryptographic material exposure is achievable via this path. Once triggered, the hung thread cannot be recovered by Java interrupt signals or application-level timeouts because the spin occurs entirely within the native JNI call frame.

The vendor-supplied CVSS 4.0 score of 8.7 with vector AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N reflects pure availability impact assessed at low attack complexity, which is defensible in the worst-case hypervisor scenario: if the VMM never forwards RDRAND/RDSEED to the guest, entropy failure is immediate and deterministic on every call, requiring zero attacker sophistication. No EPSS score was provided in the available intelligence, and the vulnerability is absent from CISA KEV, indicating no confirmed active exploitation at time of analysis. Real-world risk is strongly deployment-dependent: in cloud or VM environments where the hypervisor withholds Intel entropy instruction forwarding - a configuration found in some KVM, Xen, and older cloud provider setups - any application thread triggering native entropy seeding hangs permanently, making this a reliable, unauthenticated DoS vector against any network-exposed API. On bare-metal Intel hardware with functional on-chip entropy, the risk is meaningfully lower, as triggering the condition requires either a hardware fault or sustained DRBG exhaustion under extreme multi-core load. Scope is explicitly narrowed to bc-fips 2.1.x before 2.1.3; bcprov and the bc-fips 1.0.x and 2.0.x series are not affected, limiting the exposure surface to organizations specifically using the 2.1.x FIPS-certified release line.

In a cloud environment where the hypervisor does not forward RDRAND/RDSEED to the guest VM, any inbound request to a bc-fips 2.1.x application that triggers a cryptographic operation requiring entropy seeding - such as a TLS handshake initiation, server-side key generation, or session token creation - causes the handling thread to spin permanently inside the JNI call with no recovery possible from the Java side. No exploit code, credentials, or privileged network position are required; a remote unauthenticated attacker need only send enough such requests to exhaust the application's thread pool, taking the service offline within seconds depending on pool size.