CVE-2026-58063: Bouncy Castle Information Disclosure Flaw

CVE-2026-58063 Overview

CVE-2026-58063 affects Bouncy Castle for Java, a widely deployed cryptographic library. The vulnerability resides in the BCFKS (Bouncy Castle FIPS Key Store) load routine, which honours unbounded key derivation function (KDF) cost parameters read from an untrusted keystore file. An attacker who can supply a crafted BCFKS keystore to a target application can trigger CPU or memory exhaustion during the pre-integrity KDF phase. The issue is classified under [CWE-770: Allocation of Resources Without Limits or Throttling]. Because the KDF runs before integrity verification, no valid credentials or signatures are required to weaponize a malicious keystore.

Critical Impact
A crafted BCFKS keystore can force PBKDF2 or scrypt to consume unbounded CPU and memory during load, resulting in denial of service against any Java service that parses attacker-supplied keystores.

Affected Products

Bouncy Castle for Java before 1.85
Bouncy Castle for Java LTS before 2.73.12
Bouncy Castle for Java FIPS (BC-FJA) before bc-fips 1.0.2.7 (1.0.X), 2.0.2 (2.0.X), and 2.1.3 (2.1.X)

Discovery Timeline

2026-08-03 - CVE-2026-58063 published to NVD
2026-08-04 - Last updated in NVD database

Technical Details for CVE-2026-58063

Vulnerability Analysis

BCFKS keystores are protected by an integrity MAC whose key is derived from a password using PBKDF2 or scrypt. The KDF parameters, including the PBKDF2 iteration count and scrypt cost values (N, r, p), are stored inside the keystore itself. The affected BcFKSKeyStoreSpi implementation reads these parameters and runs the KDF before verifying the MAC. An attacker controlling the keystore file therefore controls the compute and memory cost of the KDF execution.

A typical BCFKS writer uses roughly 51,200 PBKDF2 iterations and scrypt parameters of N=16384, r=8 (about 16 MiB of working memory). By setting these fields to arbitrarily large values, an attacker forces the loader into long-running or memory-intensive computations, blocking threads and exhausting heap resources. Applications that ingest keystores from user uploads, TLS clients, or automated provisioning pipelines are directly exposed.

Root Cause

The root cause is missing input validation on cost parameters extracted from an unverified keystore. The code path processes cost values before any authenticity check, violating the principle that untrusted metadata must be bounded before consumption. The upstream fix introduces two configurable ceilings, org.bouncycastle.bcfks.max_it_count and org.bouncycastle.bcfks.max_scrypt_memory, and enforces them prior to key derivation.

Attack Vector

Exploitation requires an attacker to deliver a malicious BCFKS file to a process that calls KeyStore.load() on it. User interaction is required, typically in the form of an operator or automated workflow importing the keystore. No authentication or elevated privileges are needed against the vulnerable process.

java

// Patch excerpt: bounding BCFKS KDF cost before deriving the integrity-MAC key
// Source: https://github.com/bcgit/bc-java/commit/81737a56ef4489da1f849cf549df95e338ea6b06

/**
 * Upper bound on the PBKDF2 iteration count honoured when deriving the integrity-MAC key of a
 * BCFKS keystore during load. The KDF runs on parameters taken from the (not-yet-verified)
 * keystore, so an unbounded iteration count is a pre-integrity CPU-exhaustion vector. Default
 * 5,000,000 (the BCFKS writer uses ~51,200). Read via {@link #asInteger(String, int)}.
 */
public static final String BCFKS_MAX_IT_COUNT = "org.bouncycastle.bcfks.max_it_count";

/**
 * Upper bound, in bytes, on the working memory (~128 * N * r) of the scrypt KDF honoured when
 * deriving the integrity-MAC key of a BCFKS keystore during load. As with
 * {@link #BCFKS_MAX_IT_COUNT} the scrypt cost parameters are taken from the not-yet-verified
 * keystore, so an unbounded cost is a pre-integrity memory-exhaustion vector. Default
 * 1073741824 (1 GiB); the BCFKS writer uses N=16384, r=8 (~16 MiB). Read via
 * {@link #asInteger(String, int)}.
 */
public static final String BCFKS_MAX_SCRYPT_MEMORY = "org.bouncycastle.bcfks.max_scrypt_memory";

Source: Bouncy Castle patch commit 81737a5

Detection Methods for CVE-2026-58063

Indicators of Compromise

Java processes showing sustained high CPU usage in PKCS5S2ParametersGenerator or SCrypt stack frames during keystore load operations.
Heap allocation spikes or OutOfMemoryError events correlated with calls to KeyStore.getInstance("BCFKS").load().
Ingestion of BCFKS files whose embedded PBKDF2 iteration counts or scrypt N values greatly exceed writer defaults (51,200 iterations; N=16384, r=8).

Detection Strategies

Inspect BCFKS files at ingest time and reject those declaring PBKDF2 iterations above 5,000,000 or scrypt working memory above 1 GiB.
Instrument JVM applications with thread and heap sampling to flag KeyStore.load calls exceeding a bounded execution budget.
Correlate application logs referencing BCFKS keystore parsing errors with resource-exhaustion events on the host.

Monitoring Recommendations

Track dependency versions of bcprov, bcprov-jdk18on, and bc-fips across Java build manifests to identify vulnerable artifacts.
Alert on new or unexpected BCFKS files landing in file-upload directories, provisioning shares, or CI/CD artifact stores.
Baseline normal CPU and memory profiles for services that regularly load keystores and alert on deviations.

How to Mitigate CVE-2026-58063

Immediate Actions Required

Upgrade to Bouncy Castle for Java 1.85 or later, Bouncy Castle for Java LTS 2.73.12 or later, or the fixed BC-FJA release matching your series (1.0.2.7, 2.0.2, or 2.1.3).
Audit application code paths that invoke KeyStore.getInstance("BCFKS").load() against untrusted input.
Restrict which principals and workflows can supply BCFKS files to backend services.

Patch Information

The fix is delivered in commit 81737a5. It introduces two system properties, org.bouncycastle.bcfks.max_it_count (default 5,000,000) and org.bouncycastle.bcfks.max_scrypt_memory (default 1,073,741,824 bytes), and enforces them in BcFKSKeyStoreSpi before the integrity-MAC key is derived. Additional context is available in the Bouncy Castle CVE-2026-58063 wiki entry.

Workarounds

Set org.bouncycastle.bcfks.max_it_count and org.bouncycastle.bcfks.max_scrypt_memory to conservative values well below the defaults for environments that only load internally generated keystores.
Pre-validate BCFKS blobs with an out-of-band parser that rejects excessive KDF cost fields before passing them to Bouncy Castle.
Isolate keystore-parsing code in a resource-capped worker process or container with strict CPU and memory limits.

bash

# Enforce conservative BCFKS KDF ceilings at JVM startup
java \
  -Dorg.bouncycastle.bcfks.max_it_count=200000 \
  -Dorg.bouncycastle.bcfks.max_scrypt_memory=67108864 \
  -jar application.jar