CVE-2026-71892 in BC-JAVA
Summary
by MITRE • 10/03/2026
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).
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/03/2026
The vulnerability identified in Bouncy Castle for Java prior to version 1.86 represents a critical logic error within the Cryptographic Message Syntax implementation, specifically affecting key-transport recipients that utilize RFC 9709 content-encryption key derivation mechanisms such as id-alg-cek-hkdf-sha256. This flaw undermines the integrity of cryptographic validation by allowing mismatched key sizes to pass verification when explicit size checking is enabled via the JceKeyTransRecipient.setKeySizeValidation method. The root cause lies in a fundamental type mismatch during the conditional branching logic that determines which algorithm identifier should be used for validating the recovered encryption key. Instead of correctly identifying and comparing against the actual content-encryption algorithm specified within the HKDF parameters, the code erroneously compares the encrypted-key byte array directly against the ASN1ObjectIdentifier representing the outer wrapper OID. Since a byte array can never equal an ASN1 object identifier in Java's reference equality or standard equals implementation for these distinct types, this comparison invariably returns false. Consequently, the execution flow falls through to a secondary lookup that attempts to validate key size based on the outer wrapper OID rather than the inner content-encryption algorithm.
This logical failure results in the complete bypass of key-size validation because the outer wrapper OID identifies a key-derivation construction such as HKDF rather than a symmetric cipher, and therefore possesses no registered or defined key size constraints within the library's internal mappings. As a result, any EnvelopedData or AuthEnvelopedData structure containing an HKDF-derived content-encryption key that does not match the expected bit length of the advertised encryption algorithm is accepted without raising an exception. This silent acceptance defeats the primary security mechanism provided by the API for enforcing recovered key sizes, potentially allowing attackers to inject malformed messages with incorrect key lengths that might lead to unexpected behavior in downstream processing or weaken cryptographic assumptions if the application logic implicitly relies on specific key dimensions. The issue affects both standard Bouncy Castle implementations and the FIPS-compliant variant BC-FJA prior to versions 2.0.13 for the 2.0.X series and 2.1.13 for the 2.1.X series, indicating a systemic flaw in how these libraries handle RFC 9709 compliant key transport scenarios.
From a classification perspective, this vulnerability aligns with CWE-682 Incorrect Calculation, as the software performs an incorrect logical operation that leads to improper enforcement of security controls. It also relates closely to CWE-345 Insufficient Verification of Data Authenticity because the validation mechanism fails to properly verify the integrity and correctness of the cryptographic parameters derived from the message structure. In terms of adversary tactics, this flaw could be leveraged within ATT&CK technique T1078 Valid Accounts if an attacker can manipulate key transport messages in a protocol that relies on Bouncy Castle for decryption, potentially allowing unauthorized access or data exfiltration by bypassing expected cryptographic constraints. The operational impact is severe because it compromises the assumption that enabling strict validation will guarantee correct key dimensions, which is critical for maintaining confidentiality and integrity in secure messaging applications.
Mitigation requires immediate upgrading to patched versions of Bouncy Castle where this logic error has been corrected to properly dispatch on the content-encryption AlgorithmIdentifier's algorithm OID rather than relying on flawed byte array comparisons. For organizations unable to upgrade immediately due to legacy system constraints, implementing additional application-level validation checks that independently verify the key size after decryption can provide a compensating control. Security teams should also audit existing codebases for usage of JceKeyTransRecipient with HKDF-based algorithms and ensure that no critical security decisions are made solely based on the success of Bouncy Castle's internal validation routines without supplementary verification. Regular vulnerability scanning and dependency management practices should be enforced to prevent exposure to known flaws in cryptographic libraries, particularly those involving key transport mechanisms which are central to many secure communication protocols.