In Bouncy Castle for Java versions prior to 1.86, the opt-in key-size validation for CMS key-transport recipients using RFC 9709 content-encryption key derivation (id-alg-cek-hkdf-sha256) fails due to an incorrect comparison between a byte array and an ASN1ObjectIdentifier. This causes the validation branch to skip checking the recovered key size against the actual content-encryption algorithm, instead falling back to an outer wrapper OID that lacks a registered key size. Consequently, keys derived via HKDF that do not match the advertised content-encryption algorithm's key size are accepted silently, defeating the validation mechanism. The issue also affects Bouncy Castle for Java FIPS versions before bcpkix-fips 2.0.13 and 2.1.13. The fix involves dispatching validation based on the inner content-encryption algorithm's OID, ensuring correct key size checks. Non-HKDF messages and recipients without validation enabled are unaffected.

The vulnerability allows CMS key-transport recipients using HKDF-based content-encryption key derivation to accept keys with incorrect sizes despite explicit key-size validation being enabled. This undermines the security guarantees of the key-size validation mechanism, potentially allowing cryptographic operations with keys that do not meet expected size requirements. However, messages without HKDF or recipients not enabling validation are not impacted. There are no reports of active exploitation in the wild.

A fix is available in Bouncy Castle for Java versions 1.86 and later, and in BC-FJA versions 2.0.13 and later (2.0.X series) and 2.1.13 and later (2.1.X series). Users should upgrade to these fixed versions to ensure proper key-size validation. Until upgraded, enabling key-size validation on HKDF-based messages does not provide the intended security benefit. Patch status is confirmed by vendor advisory information embedded in the description. No additional mitigations are indicated.