Bouncy Castle BC-FJA Flaw CVE-2026-8149 Leaks GCM Keys

Executive Summary

A side-channel vulnerability designated CVE-2026-8149 has been disclosed in the Bouncy Castle FIPS Java API (BC-FJA), affecting versions 2.1.0 through 2.1.2 on Linux x86_64 systems with AVX-512f instruction set support. The flaw resides in the optimized gcm128w and gcm512w assembly routines, which leak the AES-GCM authentication subkey through a timing and power side channel. An attacker with local access or the ability to observe cryptographic operations on the same physical core could recover the GCM authentication key, enabling forgery of authenticated ciphertexts and, in some cases, plaintext recovery. The National Vulnerability Database (NVD) entry for CVE-2026-8149 was published on 2026-05-09, though the underlying advisory originates from Bouncy Castle's security disclosure process. No CVSS score has been officially assigned as of this writing, but the cryptographic nature of the flaw and the sensitivity of the leaked key material warrant a high-severity classification.

Technical Analysis

Bouncy Castle's BC-FJA is a FIPS 140-2 validated cryptographic module widely used in government, financial, and enterprise Java applications requiring certified cryptography. The vulnerability specifically targets the Galois/Counter Mode (GCM) implementation when accelerated using AVX-512f instructions on Intel and AMD processors.

The affected routines, gcm128w and gcm512w, are hand-optimized assembly functions that perform parallel GCM multiplication using 128-bit and 512-bit wide vector operations. According to the NVD description, the side channel manifests during the computation of the GCM authentication subkey (H), which is derived from the block cipher encryption of the all-zero input. An attacker who can observe execution timing, power consumption, or electromagnetic emanations from the same physical core can statistically recover this subkey over multiple encryption operations.

Once the GCM authentication subkey H is recovered, an attacker can:

• Forge authenticated ciphertexts that pass GCM integrity checks.
• Exploit known-plaintext or chosen-ciphertext scenarios to recover the underlying plaintext.
• Bypass authentication guarantees in protocols relying on GCM, such as TLS 1.3, IPsec, or SSH when using the affected module.

The vulnerability is limited to Linux x86_64 systems where the JVM exposes the AVX-512f feature flag, and BC-FJA selects the optimized code path. The affected versions are BC-FJA 2.1.0, 2.1.1, and 2.1.2. Earlier versions that do not include the AVX-512f optimized routines are not impacted. Users of the standard (non-FIPS) Bouncy Castle provider are also unaffected, as the vulnerable assembly is exclusive to the FIPS module.

Bouncy Castle has not yet released a public advisory detailing the exact disclosure timeline or whether the vulnerability was discovered internally or reported by an external researcher. The NVD entry provides only the brief description cited above, and no proof-of-concept code or exploit has been published as of May 9, 2026.

Mitigations & Recommendations

Organizations using BC-FJA in FIPS-compliant deployments should take the following steps:

1. Upgrade immediately — Bouncy Castle is expected to release BC-FJA version 2.1.3 containing a fix that disables or replaces the vulnerable AVX-512f assembly routines with constant-time alternatives. Monitor the official Bouncy Castle security page for the update.

2. Disable AVX-512f acceleration — As a temporary workaround, administrators can force the JVM to disable AVX-512f instruction support by passing the JVM flag -XX:UseAVX=0 or -XX:UseAVX=1 (limiting to AVX/AVX2 only). This will cause BC-FJA to fall back to the non-optimized, constant-time GCM implementation. Note that this may reduce throughput for bulk encryption operations.

3. Isolate cryptographic workloads — For high-security environments, consider running cryptographic operations on dedicated hardware or in isolated virtual machines to reduce the feasibility of local side-channel observation.

4. Monitor for key rotation — If the affected module has been in use on shared infrastructure (e.g., cloud instances with hyperthreading enabled), assume GCM authentication keys may have been compromised and rotate all keys generated or used by the affected versions.

5. Audit FIPS certification status — Since BC-FJA is a FIPS 140-2 validated module, any code change to address this vulnerability may require re-validation. Organizations with compliance requirements should track the certification status of the patched version.