CVE-2026-8798: Bouncy Castle Java FIPS DoS Vulnerability

CVE-2026-8798 Overview

CVE-2026-8798 is an infinite loop vulnerability [CWE-835] in Bouncy Castle for Java FIPS (BC-FJA) before version bc-fips 2.1.3. The flaw resides in the native entropy source used on Intel platforms, where the Java Native Interface (JNI) seeding routine retries the RDSEED and RDRAND CPU entropy instructions without any bound. When the on-chip entropy source fails persistently, the calling thread loops indefinitely inside the JNI call and cannot be interrupted or timed out. Any cryptographic operation drawing from the native entropy source can hang, denying service to the application.

Critical Impact
A persistent hardware entropy failure, DRBG contention across many cores, or a hypervisor that does not expose RDSEED/RDRAND can cause application threads to hang indefinitely, resulting in denial of service.

Affected Products

Bouncy Castle for Java FIPS (BC-FJA) versions before bc-fips 2.1.3
BC-FJA deployments on Intel platforms using the native entropy source
Applications performing cryptographic operations that consume native entropy on affected BC-FJA builds

Discovery Timeline

2026-08-08 - CVE-2026-8798 published to NVD
2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-8798

Vulnerability Analysis

Bouncy Castle for Java FIPS uses a native entropy source on Intel platforms that invokes the CPU instructions RDSEED and RDRAND to obtain hardware-backed randomness. Both instructions report failure through the processor carry flag. The JNI seeding routine in affected releases re-issues the instruction as long as the carry flag remains clear, with no attempt limit and no pause between iterations.

When the hardware entropy source fails to produce data, the loop never terminates. Causes include a hardware fault on the physical CPU, exhaustion of the underlying Deterministic Random Bit Generator (DRBG) under heavy multi-core contention, or execution on a hypervisor that does not implement the instruction. In each case the thread executing the JNI call spins in native code where the JVM cannot interrupt it or apply a timeout.

Bouncy Castle for Java (bcprov) is not affected because it has no native entropy source. The 1.0.X and 2.0.X FIPS series are not affected. The issue is corrected in bc-fips 2.1.3.

Root Cause

The root cause is an unbounded retry loop [CWE-835] around the RDSEED and RDRAND instructions in the native JNI entropy code. The code did not enforce an attempt ceiling, did not pause between attempts, and did not raise an error on repeated failure, leaving thread execution wholly dependent on eventual hardware success.

Attack Vector

Exploitation does not require code execution or authentication. Any condition that causes the on-chip entropy source to fail persistently triggers the hang. On virtualized infrastructure, an operator or co-tenant workload that suppresses RDSEED/RDRAND availability, or that induces sustained DRBG contention across cores, can starve BC-FJA callers of entropy and freeze application threads that request randomness.

No verified public exploit code is available. The vulnerability is described in the Bouncy Castle CVE-2026-8798 advisory.

Detection Methods for CVE-2026-8798

Indicators of Compromise

Java application threads stuck in native frames referencing the Bouncy Castle FIPS JNI entropy routines, visible in thread dumps as non-interruptible calls.
Cryptographic operations (key generation, TLS handshakes, signing) hanging without throwing an exception or returning a timeout.
Rising thread counts and thread-pool exhaustion in services that use BC-FJA for randomness on Intel or virtualized hosts.

Detection Strategies

Inventory Java applications and identify BC-FJA bc-fips versions in use; flag any release prior to 2.1.3.
Collect periodic JVM thread dumps and search for stalled frames in the BC-FJA native entropy path.
Correlate application hang events with hypervisor or CPU telemetry showing RDSEED/RDRAND unavailability or elevated failure rates.

Monitoring Recommendations

Alert on Java threads that remain in a RUNNABLE native state for durations exceeding normal cryptographic operation times.
Monitor request latency and thread-pool saturation on services performing frequent key or nonce generation.
Track platform advisories for BC-FJA and dependency management systems for outdated bc-fips artifacts.

How to Mitigate CVE-2026-8798

Immediate Actions Required

Upgrade Bouncy Castle for Java FIPS to bc-fips 2.1.3 or later across all affected applications.
Audit dependency graphs (Maven, Gradle, SBOMs) for transitive references to vulnerable bc-fips versions.
Restart Java services after upgrade to ensure the patched native library is loaded.

Patch Information

The fix in bc-fips 2.1.3 bounds the retry loops at 200 attempts for RDSEED and 20 attempts for RDRAND, matching twice the baselines in Intel's Digital Random Number Generator software implementation guide. The patched code pauses between attempts, clears any partially written buffer on exhaustion using an un-elidable memzero with a volatile pointer and an assembly memory barrier, and throws rather than continuing to spin. Details are available in the Bouncy Castle CVE-2026-8798 advisory.

Workarounds

Where upgrade is not immediately possible, configure the JVM SecureRandom provider to avoid the BC-FJA native entropy source and use an OS-provided entropy source such as /dev/urandom via java.security.egd.
On virtualized hosts, verify that the hypervisor exposes RDSEED and RDRAND to guests, or migrate BC-FJA workloads to platforms that provide reliable hardware entropy.
Apply thread-level watchdogs and circuit breakers around cryptographic call sites to surface stalled operations for operator action until patching is complete.

bash

# Configuration example: prefer OS entropy over the native BC-FJA source
java -Djava.security.egd=file:/dev/urandom -jar application.jar