Cloudanix VulnDB

CVE-2026-97873

None

CVSS

—

EPSS

0.3%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A cryptography library used by many Java programs could be tricked into doing an enormous amount of work from a single small piece of data, potentially slowing systems down or making them unresponsive.

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

What it actually does

Unbounded iteration count in legacy PBES1 and PKCS#12 PBE key derivation functions allows arbitrary CPU work from a single small untrusted input value before any verification occurs.

Why it matters to the business

Applications handling PKCS#12 keystores or password-protected private keys can be forced into prolonged computation, leading to denial of service, resource exhaustion, and operational disruption with low attacker effort.

How an attack unfolds

An attacker supplies a crafted PKCS12PBEParams or PBEParameter encoding a very large or negative iteration count; when Bouncy Castle's AlgorithmParameters or Cipher/SecretKeyFactory processes it during operations such as EncryptedPrivateKeyInfo.getKeySpec, the library performs the dictated number of iterations without bound, consuming excessive CPU before returning.

How to fix it

Upgrade Bouncy Castle for Java to 1.86 or later, or LTS release to 2.73.13 or later. Ensure the org.bouncycastle.pbe.max_iteration_count system property is set to a value no higher than 10000000; reject any encoded parameters that exceed the limit during parsing.

How to confirm the fix worked

Confirm the installed Bouncy Castle version is 1.86+ (or LTS 2.73.13+); attempt to parse a PKCS12PBEParams or PBEParameter with an iteration count above the configured maximum and verify that an exception is thrown instead of performing the work.

Typical attack path

  1. Craft a PKCS#12 keystore or EncryptedPrivateKeyInfo structure containing a PBE parameter with an extreme iteration count
  2. Deliver the structure to a target application that uses Bouncy Castle to decrypt or extract the key
  3. Trigger the decryption path (directly or via another provider's AlgorithmParameters)
  4. Force the victim to perform an unbounded number of password-based key derivation iterations

How to detect it

Review application logs and thread dumps for repeated or long-running calls inside Bouncy Castle PBE or PKCS12 key derivation classes; look for high CPU utilization correlated with inbound encrypted key material or keystore processing.

What your security team should do

  • Immediately inventory all Java applications and libraries that depend on Bouncy Castle and schedule upgrades to the fixed releases
  • Set the org.bouncycastle.pbe.max_iteration_count property to 10000000 (or lower) in all JVMs that load Bouncy Castle
  • Add dependency version checks to build pipelines and container images to prevent reintroduction of vulnerable versions
  • Monitor for sudden CPU spikes in processes that perform PKCS#12 or legacy PBE operations

The record

In Bouncy Castle for Java before 1.86, the raw JCA provider's legacy PBES1 (PKCS#5 scheme 1) and PKCS#12 PBE families ran their password-based key derivation with an iteration count taken from untrusted input without bounding it, so a small input could dictate an arbitrary amount of work before anything could be verified. The AlgorithmParameters implementations (PKCS12PBE and its object identifier aliases, and PBKDF1) accepted any count from an encoded PKCS12PBEParams or PBEParameter, narrowing a value beyond the int range with intValue(), and every Cipher, Mac and SecretKeyFactory in these families derived with whatever count it was given, including one decoded by another provider's AlgorithmParameters, as when javax.crypto.EncryptedPrivateKeyInfo.getKeySpec() decrypts a PKCS#12 PBE-protected private key with BC. Both the parameter parse and the derivations now reject a negative or over-limit count under the org.bouncycastle.pbe.max_iteration_count property (default 10,000,000) that already bounded PBKDF2 (CVE-2026-17508), and the parse rejects a count beyond the int range rather than narrowing it. This issue also affects Bouncy Castle for Java LTS before 2.73.13.

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities