In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20 for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store. Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X FIPS series are not affected.

There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel
    platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through
    their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag
    stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from
    the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not
    provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could
    be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore
    hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20
    for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation
    guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing
    rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile
    pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store.
    Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X
    FIPS series are not affected. (CVE-2026-8798)

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 2.1.3, the native entropy source used on Intel     platforms retried the CPU entropy instructions without any bound. RDSEED and RDRAND report failure through     their carry flag, and the JNI seeding routine spun re-issuing the instruction for as long as that flag     stayed clear, so a persistent failure of the on-chip entropy source - whether from a hardware fault, from     the underlying DRBG being exhausted by contention across many cores, or from a hypervisor that does not     provide the instruction - left the calling thread looping indefinitely inside the JNI call, where it could     be neither interrupted nor timed out. Any operation drawing from the native entropy source could therefore     hang, denying service to the application. The retry loops are now bounded (200 attempts for RDSEED and 20     for RDRAND, twice the baselines given in Intel's Digital Random Number Generator software implementation     guide), pausing between attempts and, on exhaustion, clearing any partially written buffer and throwing     rather than continuing to spin. The clear is performed by an un-elidable memzero, which uses a volatile     pointer and an assembly memory barrier so that a compiler cannot optimise the erase away as a dead store.
    Bouncy Castle for Java (bcprov) is not affected, as it has no native entropy source; the 1.0.X and 2.0.X     FIPS series are not affected. (CVE-2026-8798)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Type	Severity
461922	Echo: org.bouncycastle:bc-fips: security update to 2.1.3	Tenable Cloud Security	Echo Local Security Checks	Local	high
461922	Echo: org.bouncycastle:bc-fips: security update to 2.1.3	Tenable Self-Hosted Container Security	Echo Local Security Checks	Local	high
334792	Linux Distros Unpatched Vulnerability : CVE-2026-8798	Nessus	Misc.	Local	high

Detections

Analytics

CVE-2026-8798

high

Tenable Plugins

high

high

high