Legion of the Bouncy Castle BC-JAVA/BC-FJA Key Size Validation JceKeyTransRecipient.java comparison

Summaryinfo

A vulnerability was found in Legion of the Bouncy Castle BC-JAVA and BC-FJA. It has been classified as critical. Impacted is the function org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation of the file bouncycastle/cms/jcajce/JceKeyTransRecipient.java of the component Key Size Validation. This manipulation causes comparison. This vulnerability is handled as CVE-2026-71892. The attack can be initiated remotely. There is not any exploit available.

Detailsinfo

A vulnerability was found in Legion of the Bouncy Castle BC-JAVA and BC-FJA (unknown version). It has been declared as critical. Affected by this vulnerability is the function org.bouncycastle.cms.jcajce.JceKeyTransRecipient.setKeySizeValidation of the file bouncycastle/cms/jcajce/JceKeyTransRecipient.java of the component Key Size Validation. The manipulation with an unknown input leads to a comparison vulnerability. The CWE definition for the vulnerability is CWE-697. The product compares two entities in a security-relevant context, but the comparison is incorrect, which may lead to resultant weaknesses. As an impact it is known to affect confidentiality, integrity, and availability. The summary by CVE is:

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).

The advisory is shared at github.com. This vulnerability is known as CVE-2026-71892 since 08/08/2026. The exploitation appears to be easy. The attack can be launched remotely. Technical details are known, but no exploit is available. The price for an exploit might be around USD $0-$5k at the moment (estimation calculated on 10/03/2026).

There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Productinfo

Type

• Programming Language Software

Vendor

• Legion of the Bouncy Castle

Name

• BC-FJA
• BC-JAVA

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

If you want to get the best quality for vulnerability data then you always have to consider VulDB.

Discussion