CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys
Summary
| CVE | CVE-2026-71892 |
|---|---|
| State | PUBLISHED |
| Assigner | bcorg |
| Source Priority | CVE Program / NVD first with legacy fallback |
| Published | 2026-10-03 09:17:05 UTC |
| Updated | 2026-10-03 09:17:05 UTC |
| 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). |
Risk And Classification
Primary CVSS: v4.0 6.9 MEDIUM from 91579145-5d7b-4cc5-b925-a0262ff19630
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber
Problem Types: CWE-697 | CWE-697 CWE-697 Incorrect Comparison
| Version | Source | Type | Score | Severity | Vector |
|---|---|---|---|---|---|
| 4.0 | 91579145-5d7b-4cc5-b925-a0262ff19630 | Secondary | 6.9 | MEDIUM | 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/E:X/C... |
| 4.0 | CNA | CVSS | 6.9 | MEDIUM | 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 |
CVSS v4.0 Breakdown
Attack Vector
NetworkAttack Complexity
LowAttack Requirements
NonePrivileges Required
NoneUser Interaction
NoneConfidentiality
LowIntegrity
LowAvailability
NoneSub Conf.
NoneSub Integrity
NoneSub Availability
NoneCVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:Amber
Vendor Declared Affected Products
| Source | Vendor | Product | Version | Platforms |
|---|---|---|---|---|
| CNA | Legion Of The Bouncy Castle Inc. | BC-JAVA | affected 1.78 1.86 maven | all |
| CNA | Legion Of The Bouncy Castle Inc. | BC-FJA | affected 2.0.7 2.0.13 maven | all |
| CNA | Legion Of The Bouncy Castle Inc. | BC-FJA | affected 2.1.0 2.1.13 maven | all |
References
| Reference | Source | Link | Tags |
|---|---|---|---|
| github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071892 | 91579145-5d7b-4cc5-b925-a0262ff19630 | github.com | |
| github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3 | 91579145-5d7b-4cc5-b925-a0262ff19630 | github.com | |
| CVE Program record | CVE.ORG | www.cve.org | canonical |
| NVD vulnerability detail | NVD | nvd.nist.gov | canonical, analysis |
Vendor Comments And Credit
Discovery Credit
CNA: Yu Bao from the PayPal Cyber Security Team (en)
There are currently no legacy QID mappings associated with this CVE.