{"api_version":"1","generated_at":"2026-10-03T10:40:53+00:00","cve":"CVE-2026-71892","urls":{"html":"https://cve.report/CVE-2026-71892","api":"https://cve.report/api/cve/CVE-2026-71892.json","docs":"https://cve.report/api","cve_org":"https://www.cve.org/CVERecord?id=CVE-2026-71892","nvd":"https://nvd.nist.gov/vuln/detail/CVE-2026-71892"},"summary":{"title":"CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys","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).","state":"PUBLISHED","assigner":"bcorg","published_at":"2026-10-03 09:17:05","updated_at":"2026-10-03 09:17:05"},"problem_types":["CWE-697","CWE-697 CWE-697 Incorrect Comparison"],"metrics":[{"version":"4.0","source":"91579145-5d7b-4cc5-b925-a0262ff19630","type":"Secondary","score":"6.9","severity":"MEDIUM","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/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","data":{"version":"4.0","vectorString":"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","baseScore":6.9,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"LOW","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"AMBER"}},{"version":"4.0","source":"CNA","type":"CVSS","score":"6.9","severity":"MEDIUM","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","data":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":6.9,"baseSeverity":"MEDIUM","exploitMaturity":"NOT_DEFINED","privilegesRequired":"NONE","providerUrgency":"AMBER","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"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","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"LOW","vulnerabilityResponseEffort":"NOT_DEFINED"}}],"references":[{"url":"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071892","name":"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071892","refsource":"91579145-5d7b-4cc5-b925-a0262ff19630","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3","name":"https://github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3","refsource":"91579145-5d7b-4cc5-b925-a0262ff19630","tags":[],"title":"","mime":"","httpstatus":"","archivestatus":"0"},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-71892","name":"CVE Program record","refsource":"CVE.ORG","tags":["canonical"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-71892","name":"NVD vulnerability detail","refsource":"NVD","tags":["canonical","analysis"]}],"affected":[{"source":"CNA","vendor":"Legion of the Bouncy Castle Inc.","product":"BC-JAVA","version":"affected 1.78 1.86 maven","platforms":["all"]},{"source":"CNA","vendor":"Legion of the Bouncy Castle Inc.","product":"BC-FJA","version":"affected 2.0.7 2.0.13 maven","platforms":["all"]},{"source":"CNA","vendor":"Legion of the Bouncy Castle Inc.","product":"BC-FJA","version":"affected 2.1.0 2.1.13 maven","platforms":["all"]}],"timeline":[],"solutions":[],"workarounds":[],"exploits":[],"credits":[{"source":"CNA","value":"Yu Bao from the PayPal Cyber Security Team","lang":"en"}],"nvd_cpes":[],"vendor_comments":[],"enrichments":{"kev":null,"epss":null,"legacy_qids":[]},"source_records":{"cve_program":{"containers":{"cna":{"affected":[{"collectionURL":"https://www.bouncycastle.org/download/bouncy-castle-java/","defaultStatus":"unaffected","modules":["pkix"],"packageName":"bcpkix","packageURL":"pkg:maven/org.bouncycastle/bcpkix-jdk18on","platforms":["all"],"product":"BC-JAVA","programFiles":["JceKeyTransRecipient"],"repo":"https://github.com/bcgit/bc-java","vendor":"Legion of the Bouncy Castle Inc.","versions":[{"lessThan":"1.86","status":"affected","version":"1.78","versionType":"maven"}]},{"collectionURL":"https://www.bouncycastle.org/download/bouncy-castle-java-fips/","defaultStatus":"unaffected","packageName":"bcpkix-fips","packageURL":"pkg:maven/org.bouncycastle/bcpkix-fips","platforms":["all"],"product":"BC-FJA","vendor":"Legion of the Bouncy Castle Inc.","versions":[{"lessThan":"2.0.13","status":"affected","version":"2.0.7","versionType":"maven"},{"lessThan":"2.1.13","status":"affected","version":"2.1.0","versionType":"maven"}]}],"credits":[{"lang":"en","type":"reporter","value":"Yu Bao from the PayPal Cyber Security Team"}],"descriptions":[{"lang":"en","supportingMedia":[{"base64":false,"type":"text/html","value":"<p>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).</p>"}],"value":"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)."}],"metrics":[{"cvssV4_0":{"Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","Safety":"NOT_DEFINED","attackComplexity":"LOW","attackRequirements":"NONE","attackVector":"NETWORK","baseScore":6.9,"baseSeverity":"MEDIUM","exploitMaturity":"NOT_DEFINED","privilegesRequired":"NONE","providerUrgency":"AMBER","subAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","userInteraction":"NONE","valueDensity":"NOT_DEFINED","vectorString":"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","version":"4.0","vulnAvailabilityImpact":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"LOW","vulnerabilityResponseEffort":"NOT_DEFINED"},"format":"CVSS","scenarios":[{"lang":"en","value":"GENERAL"}]}],"problemTypes":[{"descriptions":[{"cweId":"CWE-697","description":"CWE-697 Incorrect Comparison","lang":"en","type":"CWE"}]}],"providerMetadata":{"dateUpdated":"2026-10-03T08:30:26.982Z","orgId":"91579145-5d7b-4cc5-b925-a0262ff19630","shortName":"bcorg"},"references":[{"tags":["vendor-advisory"],"url":"https://github.com/bcgit/bc-java/wiki/CVE%E2%80%902026%E2%80%9071892"},{"tags":["patch"],"url":"https://github.com/bcgit/bc-java/commit/be0a7d925c818ef2f338bcec55178b9b6336dfc3"}],"source":{"discovery":"EXTERNAL"},"title":"CMS key-transport recipient key-size validation never runs for RFC 9709 HKDF-derived keys","x_generator":{"engine":"bc release-notes template"}}},"cveMetadata":{"assignerOrgId":"91579145-5d7b-4cc5-b925-a0262ff19630","assignerShortName":"bcorg","cveId":"CVE-2026-71892","datePublished":"2026-10-03T08:30:26.982Z","dateReserved":"2026-08-08T00:06:07.401Z","dateUpdated":"2026-10-03T08:30:26.982Z","state":"PUBLISHED"},"dataType":"CVE_RECORD","dataVersion":"5.2"},"nvd":{"publishedDate":"2026-10-03 09:17:05","lastModifiedDate":"2026-10-03 09:17:05","problem_types":["CWE-697","CWE-697 CWE-697 Incorrect Comparison"],"metrics":{"cvssMetricV40":[{"source":"91579145-5d7b-4cc5-b925-a0262ff19630","type":"Secondary","cvssData":{"version":"4.0","vectorString":"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","baseScore":6.9,"baseSeverity":"MEDIUM","attackVector":"NETWORK","attackComplexity":"LOW","attackRequirements":"NONE","privilegesRequired":"NONE","userInteraction":"NONE","vulnConfidentialityImpact":"LOW","vulnIntegrityImpact":"LOW","vulnAvailabilityImpact":"NONE","subConfidentialityImpact":"NONE","subIntegrityImpact":"NONE","subAvailabilityImpact":"NONE","exploitMaturity":"NOT_DEFINED","confidentialityRequirement":"NOT_DEFINED","integrityRequirement":"NOT_DEFINED","availabilityRequirement":"NOT_DEFINED","modifiedAttackVector":"NOT_DEFINED","modifiedAttackComplexity":"NOT_DEFINED","modifiedAttackRequirements":"NOT_DEFINED","modifiedPrivilegesRequired":"NOT_DEFINED","modifiedUserInteraction":"NOT_DEFINED","modifiedVulnConfidentialityImpact":"NOT_DEFINED","modifiedVulnIntegrityImpact":"NOT_DEFINED","modifiedVulnAvailabilityImpact":"NOT_DEFINED","modifiedSubConfidentialityImpact":"NOT_DEFINED","modifiedSubIntegrityImpact":"NOT_DEFINED","modifiedSubAvailabilityImpact":"NOT_DEFINED","Safety":"NOT_DEFINED","Automatable":"NOT_DEFINED","Recovery":"NOT_DEFINED","valueDensity":"NOT_DEFINED","vulnerabilityResponseEffort":"NOT_DEFINED","providerUrgency":"AMBER"}}]},"configurations":[]},"legacy_mitre":{"record":{"CveYear":"2026","CveId":"71892","Ordinal":"1","Title":"CMS key-transport recipient key-size validation never runs for R","CVE":"CVE-2026-71892","Year":"2026"},"notes":[{"CveYear":"2026","CveId":"71892","Ordinal":"1","NoteData":"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).","Type":"Description","Title":"CMS key-transport recipient key-size validation never runs for R"}]}}}