Description
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).
Published: 2026-10-03
Score: 6.9 Medium
EPSS: < 1% Very Low
KEV: No
Impact: Cryptographic key validation bypass
Action: Apply patch
AI Analysis

Impact

The vulnerability lies in the key‑size validation of Bouncy Castle’s CMS key‑transport recipient when an RFC 9709 HKDF‑derived key is used. The library performs a comparison between an encrypted‑key byte array and an ASN1ObjectIdentifier that always evaluates to false, causing the code to fall back to an outer wrapper OID that lacks a defined key size. Because the size check is skipped, a key whose length does not match the advertised encryption algorithm is accepted even when key‑size validation is explicitly enabled. This flaw silently defeats the only mechanism the API provides for enforcing recovered key size, potentially compromising confidentiality.

Affected Systems

The affected products are Bouncy Castle for Java (BC‑JAVA) before version 1.86 and Bouncy Castle for FIPS (BC‑FJA) before bcpkix‑fips 2.0.13 and 2.1.13. Any application that imports CMS or AuthEnvelopedData and relies on the library’s key‑size validation for RFC 9709 HKDF content‑encryption keys can be impacted.

Risk and Exploitability

With a CVSS score of 6.9 the vulnerability is considered moderate. The EPSS score is < 1 % and it is not listed in the CISA KEV catalog. Based on the description, the attack vector is inferred to be a crafted CMS or AuthEnvelopedData message that contains an HKDF‑derived key whose length does not match the advertised algorithm and is delivered to a target that uses the vulnerable library with key‑size validation turned on. Once exploited, the flaw allows the recipient to process a message with an invalid key size, undermining the integrity of the cryptographic protection.

Generated by OpenCVE AI on October 17, 2026 at 10:02 UTC.

Remediation

No solution or workaround provided in the CVE record.

OpenCVE Recommended Actions

  • Update Bouncy Castle for Java to version 1.86 or newer and Bouncy Castle FIPS to bcpkix‑fips 2.0.13 or 2.1.13, which includes the fixed key‑size validation logic.
  • If an upgrade is not possible, avoid enabling key‑size validation for RFC 9709 HKDF key‑transport recipients by refraining from calling JceKeyTransRecipient.setKeySizeValidation(true).
  • Implement custom validation that compares the recovered key length with the inner content‑encryption algorithm’s key size before processing the message, dropping the message if a mismatch is detected.

Generated by OpenCVE AI on October 17, 2026 at 10:02 UTC.

Tracking

Sign in to view the affected projects.

Advisories

No advisories yet.

History

Wed, 14 Oct 2026 00:30:00 +0000

Type Values Removed Values Added
Weaknesses CWE-1024
References
Metrics threat_severity

None

 cvssV3_1

{'score': 6.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N'}

threat_severity

Moderate

Mon, 05 Oct 2026 17:30:00 +0000

Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}

Sun, 04 Oct 2026 20:45:00 +0000

Type Values Removed Values Added
First Time appeared Legion Of The Bouncy Castle Inc.
Legion Of The Bouncy Castle Inc. bc-fja
Legion Of The Bouncy Castle Inc. bc-java
Vendors & Products Legion Of The Bouncy Castle Inc.
Legion Of The Bouncy Castle Inc. bc-fja
Legion Of The Bouncy Castle Inc. bc-java

Sat, 03 Oct 2026 08:45:00 +0000

Type Values Removed Values Added
Description 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).
Title CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys
Weaknesses CWE-697
References
Metrics cvssV4_0

{'score': 6.9, 'vector': 'CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/U:Amber'}

Subscriptions

Legion Of The Bouncy Castle Inc. Bc-fja Bc-java
cve-icon MITRE

Status: PUBLISHED

Assigner: bcorg

Published:

Updated: 2026-10-05T16:58:40.411Z

Reserved: 2026-08-08T00:06:07.401Z

Link: CVE-2026-71892

cve-icon Vulnrichment

Updated: 2026-10-05T16:58:31.672Z

cve-icon NVD

Status : Awaiting Analysis

Published: 2026-10-03T09:17:05.913

Modified: 2026-10-06T14:49:40.823

Link: CVE-2026-71892

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-10-03T08:30:26Z

Links: CVE-2026-71892 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-10-17T10:15:07Z

Weaknesses