Bouncy Castle Java CVE-2026-71892

Three conditions must all hold: (1) the receiving application must have explicitly enabled the opt-in control JceKeyTransRecipient.setKeySizeValidation(true), which is OFF by default; (2) the processed message must be a key-transport EnvelopedData or AuthEnvelopedData using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256); and (3) the HKDF-derived content-encryption key size must not match the advertised inner content-encryption algorithm. Limiting factors that reduce real-world risk: the validation is opt-in and non-default, so applications that never call setKeySizeValidation(true) are unaffected; non-HKDF messages are unaffected; messages whose key size already matches are unaffected; and the flaw bypasses a size-enforcement check rather than directly decrypting data or recovering keys.

This is a medium-severity defense-in-depth control failure, not a high-impact primitive. The vendor CVSS 4.0 base score is 6.9 (U:Amber) with vector AV:N/AC:L/AT:N/PR:N/UI:N and Low vulnerable-system confidentiality and integrity impact (VC:L/VI:L), which already signals limited rather than severe consequences. No EPSS probability, no CISA KEV listing, and no standalone public exploit were supplied, so there is no evidence of active or at-scale exploitation; the only exploitation artifact is a regression test shipped inside the patch commit, which demonstrates the condition but is not a weaponized exploit. CAVEAT ON THE VECTOR: the CVSS metrics state PR:N/UI:N (remote, unauthenticated, no interaction), but the description makes clear the flaw only matters when the receiving application has explicitly opted in via JceKeyTransRecipient.setKeySizeValidation(true) AND the message uses RFC 9709 HKDF CEK derivation - those are target-side preconditions not reflected in the base vector, so real-world reachability is far narrower than AV:N/PR:N implies. The practical effect is that an optional, non-default key-size enforcement check silently passes when it should fail (CWE-697, incorrect comparison of a byte array against an ASN1ObjectIdentifier). This is a real correctness/security-control bug worth patching, but it is a low-real-risk issue for most deployments: it does not by itself enable decryption, code execution, or key recovery, and it is inert for every application that never enabled the opt-in validation.

An attacker crafts a key-transport EnvelopedData or AuthEnvelopedData using RFC 9709 HKDF content-encryption key derivation (id-alg-cek-hkdf-sha256) in which the HKDF-derived content-encryption key size does not match the advertised content-encryption algorithm (e.g. 256 bits of keying material while the inner algorithm is AES-128-CBC). A recipient application that relies on setKeySizeValidation(true) as a security boundary accepts the mismatched message because the faulty OID comparison skips the size check entirely, defeating the only API-level key-size enforcement the library offers. A regression test demonstrating this condition ships with the patch, but no standalone public exploit was identified at time of analysis.