Cloudanix VulnDB

CVE-2026-71892

None

CVSS

—

EPSS

0.2%

Published

Oct 3, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A flaw in a widely used encryption library can let specially formatted secure messages slip through a size check that was supposed to protect them, so organizations should update the library to restore the intended protection.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Data Tampering
Component
Library
Class
Cryptographic Weakness
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Bypasses opt-in key-size validation for CMS key-transport recipients using RFC 9709 HKDF-derived content-encryption keys by performing an always-false byte-array-to-OID comparison, causing the check to fall through to an unregistered outer OID and silently accept mismatched recovered keys.

Why it matters to the business

Undermines the sole API mechanism for enforcing content-encryption key sizes in enveloped CMS processing, raising the risk of accepting cryptographically invalid keys in applications that rely on Bouncy Castle for secure message handling.

How an attack unfolds

An attacker crafts an AuthEnvelopedData or EnvelopedData message that uses id-alg-cek-hkdf-sha256 key derivation with a transported key whose length does not match the advertised inner content-encryption algorithm; the recipient library with setKeySizeValidation(true) enabled still accepts the message because the faulty dispatch logic skips the size check entirely.

How to fix it

Upgrade Bouncy Castle for Java to 1.86 or later; for FIPS modules upgrade bcpkix-fips to 2.0.13 (2.0 series) or 2.1.13 (2.1 series). Rebuild and redeploy all dependent applications after the library update. Applications that do not enable setKeySizeValidation remain unaffected but should evaluate whether validation should be enabled post-upgrade.

How to confirm the fix worked

Confirm the Bouncy Castle version in the classpath or Maven/Gradle dependency tree matches or exceeds the fixed releases; exercise CMS recipient code paths with both HKDF and non-HKDF test vectors while validation is enabled and verify that mismatched key sizes are rejected.

Typical attack path

  1. Identify a target application that uses Bouncy Castle CMS recipients with explicit key-size validation enabled
  2. Generate a CMS EnvelopedData or AuthEnvelopedData structure containing an HKDF-derived CEK whose length mismatches the advertised cipher
  3. Deliver the malformed message to the recipient via any transport the application accepts
  4. Trigger recipient processing so the library performs key transport and key-size validation
  5. Observe successful decryption or acceptance despite the size mismatch

How to detect it

Review application logs for CMS recipient initialization or key-transport events around the time of message processing; look for successful decryption of EnvelopedData structures that use id-alg-cek-hkdf-sha256 where key-size validation was requested.

What your security team should do

  • Prioritize upgrade of Bouncy Castle in any environment performing CMS key-transport with explicit key-size validation
  • Inventory all direct and transitive Bouncy Castle usages across Java applications and services
  • Add the updated library version to dependency-enforcement policies and CI build gates
  • Review logging around CMS recipient processing to ensure validation failures are observable

The record

In Bouncy Castle for Java before 1.86, the opt-in key-size validation on CMS key-transport recipients, org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation(true), never ran for a message using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256). The branch that should have selected the actual content-encryption algorithm carried in the key derivation AlgorithmIdentifier's parameters compared the encrypted-key byte array against the id-alg-cek-hkdf-sha256 object identifier, a comparison between a byte array and an ASN1ObjectIdentifier that is false for every possible input, so the check fell through to a key-size lookup on the outer wrapper OID. That OID identifies a key-derivation construction rather than a cipher and has no registered key size, so the size comparison was skipped entirely. A key-transport EnvelopedData or AuthEnvelopedData whose transported, HKDF-derived content-encryption key did not match the key size of the advertised content-encryption algorithm was therefore accepted even with validation explicitly enabled, silently defeating the only mechanism the API offers for enforcing recovered key size. The recipient now dispatches on the content-encryption AlgorithmIdentifier's algorithm OID, so validation checks the recovered key against the inner content-encryption algorithm. Messages with a matching key size, non-HKDF messages, and recipients that do not enable validation are unaffected. This issue also affects Bouncy Castle for Java FIPS (BC-FJA) before bcpkix-fips 2.0.13 (2.0.X series) and 2.1.13 (2.1.X series).

Affected packages

Ecosystem Package Introduced Fixed

Related vulnerabilities