Cloudanix VulnDB

CVE-2026-17508

None

CVSS

—

EPSS

0.4%

Published

Oct 2, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A library used to handle encrypted files and keys can be tricked into performing an enormous amount of work from a tiny malicious input, potentially slowing down or crashing applications until the problem is fixed by an update.

Exploitation
Requires User Interaction
Attacker needs
User Interaction
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Improper Input Validation
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Unbounded cost parameters (iteration counts, parallelization, rounds) taken directly from untrusted input cause arbitrary CPU and memory consumption during PBKDF2, scrypt, bcrypt, and PBMAC1 derivation before any integrity or password check occurs.

Why it matters to the business

Attackers can trigger resource exhaustion on servers or applications that parse untrusted encrypted files, PKCS#12 containers, or OpenSSH private keys, leading to degraded performance or outages without requiring authentication.

How an attack unfolds

An attacker supplies a crafted PBMAC1Params, PKCS#12 structure, PBKDF2 parameter set, or OpenSSH v1 key containing an extremely large iteration count, scrypt p value, or round count; the library performs the full KDF work dictated by the attacker before any MAC or password validation can reject the input.

How to fix it

Upgrade Bouncy Castle for Java to 1.86 or later, Bouncy Castle LTS to 2.73.13 or later, or BC-FJA to bcpkix-fips 1.0.13 / 2.0.13 / 2.1.13 as appropriate for the release line; set the org.bouncycastle.openssh.max_rounds property if OpenSSH key handling is used.

How to confirm the fix worked

Confirm the deployed Bouncy Castle jar version matches a fixed release, then exercise the affected builders and parsers with inputs containing cost parameters above the new internal caps to verify immediate rejection occurs.

Typical attack path

  1. Identify an entry point that accepts untrusted encrypted or key material (PKCS#12, PKCS#8, OpenSSH key, or raw PBKDF2 parameters).
  2. Craft input that sets an excessively high cost parameter (iterations, p, or rounds) while keeping the structure syntactically valid.
  3. Submit the input to the affected JcePBMac1CalculatorBuilder, PKCS12PfxPdu.isMacValid, PBEPBKDF2, or OpenSSH key parser.
  4. Observe sustained high CPU and memory usage as the library executes the attacker-chosen KDF workload before any rejection occurs.

How to detect it

Inspect application logs and process metrics for sudden spikes in CPU or memory during parsing of PKCS#12, PKCS#8, or OpenSSH private-key material; correlate with requests that supply encrypted blobs or key files from untrusted origins.

What your security team should do

  • Apply the version upgrades listed in remediation guidance within the next maintenance window.
  • Add the org.bouncycastle.openssh.max_rounds property to any configuration that processes OpenSSH private keys.
  • Review and restrict any code paths that parse PKCS#12, PKCS#8, or OpenSSH material received from external sources.
  • Monitor CPU and memory usage on services that perform password-based key derivation from untrusted data.

The record

In Bouncy Castle for Java before 1.86, several password-based key derivation entry points ran the KDF with cost parameters taken from the untrusted input being processed, without bounding them, so a small input could dictate an arbitrary amount of work before any password or integrity check could reject it. The affected paths are the RFC 9579 PBMAC1 MAC calculator builders, which took the PBKDF2 iteration count and derived-key length straight out of PBMAC1Params (JcePBMac1CalculatorBuilder, and PKCS12PBEUtils.createPBMac1Calculator reached from PKCS12PfxPdu.isMacValid); the scrypt parallelization parameter p in the PKCS#8 and PKCS#12 cost guards, which bounded only the cost parameter N and the block size r even though the scratch buffer scales with r times p, so the configured memory ceiling could be evaded entirely; the raw JCA PBKDF2 provider (org.bouncycastle.jcajce.provider.symmetric.PBEPBKDF2); and the bcrypt round count read from an encrypted OpenSSH v1 private key's own kdfoptions. Each now bounds the parameter before deriving, in line with the caps already applied elsewhere in the tree, with the OpenSSH round count configurable through the new org.bouncycastle.openssh.max_rounds property. This completes the bounding begun in 1.85 for the PKCS#8 / PBES2 decryptors (CVE-2026-15055). This issue also affects Bouncy Castle for Java LTS before 2.73.13, and Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 1.0.13 (1.0.X series), 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities