CVE-2026-8798

What it actually does

On Intel platforms, Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3 seeds from a JNI native entropy source that re-issues RDSEED and RDRAND with no retry limit when the CPU carry flag reports failure. A persistent instruction failure—hardware fault, a hypervisor that does not provide the instructions, or on-chip DRBG exhaustion under multi-core contention—leaves the calling thread spinning inside the JNI call, where it cannot be interrupted or timed out. Any cryptographic operation that draws native entropy can hang indefinitely, producing a high-availability denial of service with no confidentiality or integrity impact. Bouncy Castle bcprov is not affected (no native entropy source); the 1.0.X and 2.0.X FIPS series are not affected.

Why it matters to the business

Java services that use Bouncy Castle FIPS on Intel can stop handling work when they need randomness for TLS, key generation, or other FIPS crypto, because worker threads never return from native seeding. That can exhaust thread pools, stall handshakes, and cascade timeouts to dependent systems. The CVE is not in CISA KEV, is not associated with ransomware, has no known exploit maturity, and EPSS is low and flat (~0.0043 over 30 days), so mass opportunistic attacks are unlikely. Residual risk is still operational wherever BC-FJA native entropy sits on a production hot path, especially in virtualized or highly concurrent Intel environments. The issue has been public for about two months; treat it as an availability patch, not an emergency remote-code-execution event.

How an attack unfolds

Exploitation does not require a memory-corruption payload. The attacker needs a target running vulnerable BC-FJA on Intel where RDSEED/RDRAND can fail persistently or be exhausted, then induces the application to draw native entropy. Unauthenticated or otherwise permitted traffic that triggers TLS, key agreement, FIPS SecureRandom, or key generation is sufficient. Each request can pin a thread in an uninterruptible JNI retry loop; repeating or parallelizing those requests drains the thread pool and denies service. In guests whose hypervisor never implements the instructions, a single entropy draw can hang; under heavy concurrency the attacker can raise failure rates by driving many simultaneous crypto operations. No named threat actors or campaigns are associated, and there is no public exploit maturity.

How to fix it

Upgrade Bouncy Castle for Java FIPS to bc-fips 2.1.3 or later. That release bounds retries (200 for RDSEED, 20 for RDRAND), pauses between attempts, clears any partial buffer with an un-elidable memzero, and throws instead of spinning. Do not confuse this with bcprov (unaffected) or the 1.0.X and 2.0.X FIPS lines (unaffected). If you cannot upgrade immediately, ensure Intel hypervisors expose RDRAND/RDSEED, cap concurrent operations that seed from native entropy, and enforce request timeouts and thread-pool limits so a hung JNI call cannot consume the entire service. Rebuild and redeploy any shaded or vendored BC-FJA artifacts.

How to confirm the fix worked

Inventory runtimes and lockfiles for bc-fips artifacts older than 2.1.3, excluding bcprov and 1.0.X/2.0.X FIPS. After upgrade, confirm 2.1.3 or newer in manifests and resolved dependencies. Exercise entropy-heavy paths (TLS, key generation, FIPS RNG) under load and on Intel guests that may lack RDRAND/RDSEED; operations should fail fast with an exception rather than hang. Capture thread dumps during a controlled entropy-failure test and verify native seeding frames return or throw instead of spinning indefinitely.

Typical attack path

1. Locate a Java service using Bouncy Castle FIPS (BC-FJA) before bc-fips 2.1.3 on Intel, especially a VM or highly concurrent host where RDSEED/RDRAND may fail or be exhausted.
2. Identify application workflows that pull the native entropy source (TLS, key generation, FIPS RNG, or similar).
3. Send permitted requests that force those entropy-consuming operations.
4. Increase concurrency if needed so many cores contend for the on-chip DRBG and persistent instruction failure becomes more likely.
5. Allow worker threads to remain stuck in the JNI seeding call until the pool is exhausted and the service stops responding.

How to detect it

This issue leaves no classic malware implant; hunt for availability incidents and stuck native threads, not a network exploit signature. Review JVM thread dumps and flight recordings from outage windows for threads that remain RUNNABLE in Bouncy Castle FIPS JNI entropy seeding across successive dumps, with no exception and no progress. Correlate with Intel hosts or VMs, stalled TLS or key-generation work, and recovery only after workers are killed. Check whether the hypervisor advertised or passed through RDRAND/RDSEED. Application logs may show handshakes or key generation that never complete until the pool is exhausted. Confirm whether bc-fips older than 2.1.3 was on the classpath. No named APT activity is tied to this CVE; post-exploitation artifacts are not expected because impact is hang-only.

• bc-fips-2.1.0
• bc-fips-2.1.1
• bc-fips-2.1.2
• RDSEED
• RDRAND
• bc-fips

What your security team should do

• Identify and upgrade all BC-FJA bc-fips 2.1.x deployments below 2.1.3; treat bcprov and 1.0.X/2.0.X FIPS as out of scope.
• Patch Intel hosts and virtualized workloads that terminate TLS or generate keys with FIPS Java crypto first, where a hang is most likely to cause an outage.
• Until patched, alert on long-lived JNI/native threads, request timeouts, and thread-pool exhaustion around crypto and TLS.
• Verify hypervisor CPU feature passthrough for RDRAND/RDSEED on Intel guests to remove a common environmental trigger.
• Given low EPSS, no KEV listing, and no known exploitation, schedule this as a high-availability fix rather than an emergency RCE response, but do not defer production FIPS TLS and key-generation paths.