CVE-2026-71892: 
Bouncy Castle Analyse et atténuation des vulnérabilités

CVE-2026-71892 is a security feature bypass vulnerability in Bouncy Castle for Java (bcpkix) affecting versions 1.78 through 1.85, and in the FIPS variant (bcpkix-fips) versions 2.0.7–2.0.12 and 2.1.0–2.1.12. The flaw causes the opt-in key-size validation control (JceKeyTransRecipient.setKeySizeValidation(true)) to silently fail when processing CMS key-transport messages that use RFC 9709 HKDF-derived content-encryption keys (id-alg-cek-hkdf-sha256). It was discovered by Yu Bao from the PayPal Cyber Security Team and disclosed on October 3, 2026. The vulnerability carries a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory, bc-java Wiki).

The root cause is an incorrect comparison (CWE-697) in JceKeyTransRecipient.java. The validation branch intended to detect RFC 9709 HKDF-wrapped keys evaluated encryptedEncryptionKey.equals(CMSObjectIdentifiers.id_alg_cek_hkdf_sha256), where encryptedEncryptionKey is a raw byte[] of RSA-wrapped ciphertext. Because byte[] does not override Object.equals(), this comparison between an array reference and an ASN1ObjectIdentifier singleton is always false, making the intended branch permanently unreachable. Control fell through to a key-size lookup against the outer id-alg-cek-hkdf-sha256 OID, which names a key-derivation construction rather than a cipher and has no registered key size in DefaultSecretKeySizeProvider, so the size check was skipped entirely for any key length. The fix (commit be0a7d9) changes the condition to encryptedKeyAlgorithm.getAlgorithm().equals(CMSObjectIdentifiers.id_alg_cek_hkdf_sha256), correctly dispatching on the algorithm OID and unwrapping the inner content-encryption AlgorithmIdentifier before performing the key-size check (bc-java Wiki, bc-java Commit).

The practical impact is the silent defeat of an explicitly-requested cryptographic policy control. An attacker who controls the CMS message structure (e.g., a malicious sender) can advertise one content-encryption algorithm (such as AES-256-CBC) while transporting a key of a different size (e.g., 128-bit), and a recipient with setKeySizeValidation(true) will accept the message without error. Because Java's AES Cipher selects key strength by the actual key bytes rather than the declared OID, decryption may succeed silently with the wrong key size, undermining key-strength enforcement policies. Direct plaintext exposure requires the attacker to also possess the recipient's private key, so the primary risk is policy bypass rather than immediate confidentiality loss (bc-java Wiki, GitHub Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). Exploitation requires an attacker to craft a malicious CMS EnvelopedData or AuthEnvelopedData message using RFC 9709 HKDF key derivation with a mismatched content-encryption key size, and deliver it to a recipient application that has explicitly enabled setKeySizeValidation(true) — a non-default, opt-in setting. No threat actor attribution, CISA KEV listing, or EPSS score data is currently available for this CVE.

1. Identify a target application: Determine that the target Java application uses Bouncy Castle bcpkix versions 1.78–1.85 (or bcpkix-fips 2.0.7–2.0.12 / 2.1.0–2.1.12) and has explicitly enabled JceKeyTransRecipient.setKeySizeValidation(true) when processing CMS messages.
2. Craft a malicious CMS EnvelopedData message: Using a Bouncy Castle API or equivalent CMS tooling, construct a CMSEnvelopedData message that uses RFC 9709 HKDF-SHA256 content-encryption key derivation (id-alg-cek-hkdf-sha256) and specifies a content-encryption algorithm (e.g., AES-256-CBC) whose declared key size does not match the actual transported key (e.g., supply a 128-bit key instead of 256-bit).
3. Encrypt to the recipient's certificate: Use the legitimate recipient's X.509 certificate to wrap the mismatched key via RSA key transport, producing a valid-looking KeyTransRecipientInfo structure.
4. Deliver the message: Transmit the crafted CMS message to the target application through whatever channel it accepts (e.g., S/MIME email, API endpoint, file upload).
5. Observe silent acceptance: The vulnerable application's key-size validation silently passes due to the always-false OID comparison, accepting the message without raising a CMSException, thereby bypassing the enforced key-size policy (bc-java Wiki, bc-java Commit).

Upgrade to the fixed versions: bcpkix 1.86 or later, bcpkix-fips 2.0.13 or later (2.0.x series), or bcpkix-fips 2.1.13 or later (2.1.x series). No configuration-based workaround is available since the validation mechanism itself is broken for HKDF messages; disabling setKeySizeValidation is not a mitigation but merely removes the broken check. Applications that rely on key-size validation as a security control — particularly those processing CMS messages with RFC 9709 HKDF-derived keys — should prioritize this upgrade (bc-java Wiki, GitHub Advisory).

The vulnerability was credited to Yu Bao from the PayPal Cyber Security Team, indicating responsible disclosure through an established security research channel. The Bouncy Castle maintainers published a detailed wiki entry and released the fix promptly in version 1.86. No significant broader media coverage or notable community commentary beyond the official advisory has been observed at this time (bc-java Wiki).