The vulnerability resides in the key‑size validation logic of Bouncy Castle’s CMS key‑transport recipient when an RFC 9709 HKDF‑derived key is used. The library performs an unnecessary comparison between a byte array of the encrypted key and an ASN1ObjectIdentifier, which always evaluates to false. Consequently, the fallback key‑size check is performed against the outer wrapper OID rather than the inner content‑encryption algorithm. Because that OID does not define a key size, the size comparison is skipped entirely, allowing a key whose length does not match the advertised algorithm to be accepted even when validation is explicitly enabled. This flaw represents a cryptographic key‑validation bypass that can compromise confidentiality by permitting the use of invalid key sizes.

The affected products are Bouncy Castle for Java (BC‑JAVA) before version 1.86 and Bouncy Castle for FIPS (BC‑FJA) before bcpkix‑fips 2.0.13 and 2.1.13. Any application that imports CMS or AuthEnvelopedData and relies on the library’s key‑size validation for RFC 9709 HKDF content‑encryption keys is potentially impacted.

With a CVSS score of 6.9 the vulnerability is considered moderate. No EPSS data is available, and it is not listed in the CISA KEV catalog. Exploitation requires the attacker to craft a CMS‑wrapped message containing an HKDF‑derived key whose length does not match the advertised algorithm and deliver it to a target that uses the vulnerable library with key‑size validation turned on. The attack surface is limited to applications that explicitly enable this validation. Once exploited, the flaw undermines the cryptographic integrity of the message stream.