CVE-2026-15055: Bouncy Castle Information Disclosure Bug

CVE-2026-15055 Overview

CVE-2026-15055 affects Bouncy Castle for Java cryptographic libraries. The vulnerability exists in PKCS#8 and PBES2 decryptors that honour unbounded key derivation function (KDF) cost parameters from input. Attacker-supplied encrypted key material can specify arbitrarily large PBKDF2 iteration counts or scrypt memory parameters, forcing the decryption process to consume excessive CPU or memory resources. The flaw is tracked under CWE-770: Allocation of Resources Without Limits or Throttling.

Critical Impact
Applications processing untrusted PKCS#8 or PEM-encoded private keys can be forced into CPU-exhaustion or memory-exhaustion conditions, enabling denial-of-service against services that accept user-supplied encrypted keys.

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) bcpkix-fips before 1.0.12 (1.0.X), 2.0.12 (2.0.X), and 2.1.12 (2.1.X)

Discovery Timeline

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

Technical Details for CVE-2026-15055

Vulnerability Analysis

The vulnerability resides in Bouncy Castle's handling of PBES2-protected PKCS#8 private key containers. When decrypting these containers, the library reads KDF parameters (PBKDF2 iteration count or scrypt cost factors) directly from the encrypted key structure without applying any upper bound. Because the key derivation parameters travel inside the unauthenticated portion of the encrypted-key container, an attacker who can supply key material to a parsing application controls the computational cost of decryption.

The attack path targets any application that accepts encrypted PKCS#8 or PEM-encoded private keys from untrusted sources. Examples include certificate management portals, key upload endpoints, code-signing services, and identity provisioning APIs. Processing a single malicious key can pin a CPU core or exhaust available heap memory.

Root Cause

The root cause is missing validation on KDF cost parameters extracted from PBES2AlgorithmIdentifier structures. The JceOpenSSLPKCS8DecryptorProviderBuilder and related decryption paths accepted any iteration count or scrypt N/r values embedded in the input, treating attacker-controlled cost factors as trusted configuration.

Attack Vector

Exploitation requires an attacker to submit a crafted PKCS#8 or PEM private key to an application using a vulnerable Bouncy Castle version. User interaction is required (UI:P) because a user or system must initiate the key parsing operation. The result is availability impact through CPU or memory exhaustion.

java

      */
     public static final String BCFKS_MAX_SCRYPT_MEMORY = "org.bouncycastle.bcfks.max_scrypt_memory";
 
+    /**
+     * Upper bound on the PBKDF2 iteration count honoured when decrypting a PBES2-protected
+     * PKCS#8 / PEM private key. The key-derivation parameters travel inside the (unauthenticated)
+     * encrypted-key container, so an unbounded count makes decrypting attacker-supplied key
+     * material a CPU-exhaustion vector. Default 10,000,000, generous enough for deliberately
+     * strong settings. Read via {@link #asInteger(String, int)}.
+     */
+    public static final String PBE_MAX_ITERATION_COUNT = "org.bouncycastle.pbe.max_iteration_count";
+
+    /**
+     * Upper bound, in bytes, on the scrypt working memory (~128 * N * r) honoured when decrypting
+     * a PBES2-protected PKCS#8 / PEM private key. As with {@link #PBE_MAX_ITERATION_COUNT} the
+     * scrypt cost travels in the unauthenticated container, so an unbounded cost is a
+     * memory-exhaustion vector. Default 1073741824 (1 GiB). Read via {@link #asInteger(String, int)}.
+     */
+    public static final String PBE_MAX_SCRYPT_MEMORY = "org.bouncycastle.pbe.max_scrypt_memory";
+
     private Properties()
     {
     }

Source: Bouncy Castle patch commit 7ab4ee6. The patch introduces two new properties, org.bouncycastle.pbe.max_iteration_count (default 10,000,000) and org.bouncycastle.pbe.max_scrypt_memory (default 1 GiB), which bound the KDF cost accepted from encrypted key inputs.

Detection Methods for CVE-2026-15055

Indicators of Compromise

Sustained high CPU utilization in JVM processes correlated with private-key upload or import operations.
Java heap exhaustion or OutOfMemoryError events triggered by PKCS#8 or PEM key parsing.
Repeated submissions of encrypted key material from a single source targeting key management endpoints.

Detection Strategies

Inventory Java applications and identify dependencies on bcprov, bcpkix, and bcpkix-fips at versions below the fixed releases using software composition analysis.
Instrument code paths that invoke JceOpenSSLPKCS8DecryptorProviderBuilder or PKCS8EncryptedPrivateKeyInfo to log iteration counts and scrypt parameters observed in input.
Alert on decryption operations exceeding a threshold duration (for example, greater than 5 seconds) as an anomaly indicator.

Monitoring Recommendations

Monitor application performance metrics for latency spikes and thread contention on services that accept user-supplied private keys.
Correlate JVM garbage collection pressure and CPU saturation events with request logs on key-import APIs.
Track dependency versions of Bouncy Castle across build pipelines and container images to detect drift back to vulnerable versions.

How to Mitigate CVE-2026-15055

Immediate Actions Required

Upgrade Bouncy Castle for Java to 1.85 or later, LTS to 2.73.12 or later, and BC-FJA bcpkix-fips to 1.0.12, 2.0.12, or 2.1.12 depending on branch.
Audit application endpoints that parse untrusted PKCS#8 or PEM private keys and enforce request timeouts and memory limits.
Set the org.bouncycastle.pbe.max_iteration_count and org.bouncycastle.pbe.max_scrypt_memory system properties to values appropriate for the deployment.

Patch Information

The fix is available in the Bouncy Castle commit 7ab4ee6 and documented in the Bouncy Castle CVE-2026-15055 wiki entry. The patch modifies Properties.java and JceOpenSSLPKCS8DecryptorProviderBuilder.java to enforce bounded KDF cost parameters.

Workarounds

If patching is not immediately possible, configure the JVM to set -Dorg.bouncycastle.pbe.max_iteration_count and -Dorg.bouncycastle.pbe.max_scrypt_memory to conservative limits after applying the update.
Restrict key-import functionality to authenticated administrative users and rate-limit submissions.
Reject encrypted PKCS#8 keys larger than a reasonable size threshold before invoking Bouncy Castle decoders.

bash

# Configuration example - bound PBES2 KDF cost via JVM system properties
java \
  -Dorg.bouncycastle.pbe.max_iteration_count=1000000 \
  -Dorg.bouncycastle.pbe.max_scrypt_memory=134217728 \
  -jar your-application.jar