CVE-2026-8798: 
Chainguard vulnerability analysis and mitigation

CVE-2026-8798 is a Denial of Service vulnerability in Bouncy Castle for Java FIPS (BC-FJA) caused by an unbounded retry loop in the native entropy source on Intel platforms. The JNI seeding routine retried the RDSEED and RDRAND CPU entropy instructions indefinitely when they reported failure via the carry flag, leaving the calling thread permanently blocked inside the JNI call with no ability to interrupt or time out. The vulnerability affects BC-FJA versions 2.1.0 through 2.1.2 (fixed in 2.1.3); the standard Bouncy Castle for Java (bcprov) and the 1.0.X/2.0.X FIPS series are not affected. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory, BC-Java Wiki).

The root cause is CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop) in the native entropy source implementation (rand_jni.c) backing org.bouncycastle.crypto.fips.NativeEntropySource. Intel's RDSEED and RDRAND instructions signal failure through the CPU carry flag; the JNI seeding routine checked this flag but had no upper bound on retries, spinning indefinitely when the flag remained clear due to hardware faults, DRBG exhaustion under high core contention, or a hypervisor that does not expose the instruction. Because the infinite loop executes in native code, it cannot be interrupted or timed out from the Java layer, making the affected thread unrecoverable. The fix bounds retries to 200 attempts for RDSEED and 20 for RDRAND (twice Intel's recommended baselines), adds _mm_pause() between attempts, and on exhaustion clears any partially written buffer via an un-elidable memzero (volatile pointer plus assembly memory barrier) before throwing an exception (BC-Java Wiki, GitHub Advisory).

Successful exploitation causes a complete availability loss for any application operation that draws from the native entropy source, as the affected thread hangs indefinitely and cannot be recovered without restarting the JVM process. There is no confidentiality or integrity impact; however, the secondary risk of a partially written entropy buffer being observable alongside a thrown exception was also addressed in the fix via the un-elidable memzero. In environments where cryptographic operations are on the critical path — such as TLS handshakes, key generation, or FIPS-compliant signing — a triggered hang can render the entire application unresponsive (GitHub Advisory, BC-Java Wiki).

No public proof-of-concept exploit code exists and no in-the-wild exploitation has been reported (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.33% (26th percentile), indicating a low near-term exploitation probability. Triggering the condition requires influence over platform entropy — such as operating as a hypervisor that withholds the RDSEED/RDRAND instructions, inducing hardware-level entropy exhaustion, or causing sustained DRBG contention across many cores — which limits the practical attacker pool primarily to infrastructure operators or privileged cloud tenants (GitHub Advisory).

The primary remediation is to upgrade BC-FJA to version 2.1.3 or later, which bounds the RDSEED retry loop to 200 attempts and the RDRAND loop to 20 attempts before throwing an exception (BC-Java Wiki, GitHub Advisory). As a workaround where immediate upgrade is not possible, ensure that Intel RDSEED and RDRAND instructions are properly exposed and functional on the target platform, and that the underlying DRBG is not subject to sustained exhaustion under normal operating conditions. Hypervisor configurations should be reviewed to confirm that hardware entropy instructions are passed through to guest VMs running BC-FJA. Monitor for unexpected application hangs in cryptographic operations as an operational indicator of the condition being triggered.