Bouncy Castle Java CVE-2026-12802

The application must use Bouncy Castle's CMS AuthEnvelopedData decryption path - specifically, one of the JCE recipient types (JceKeyTransRecipient, JceKeyAgreeRecipient, JceKEMRecipient, JcePasswordRecipient, or JceKEKRecipient) - and must process CMS messages received from an attacker-controlled or attacker-influenceable source. The attacker must be able to deliver a crafted CMS AuthEnvelopedData message to the application and must have access to the target recipient's public key material (certificate or public key) to construct a valid key-wrapping layer. Applications that only generate CMS messages (encrypt/sign only) or that process only CMS SignedData or EnvelopedData (non-authenticated) are not affected. Applications consuming CMS payloads exclusively from fully trusted internal sources face minimal real-world risk. The CVSS vector PR:N indicates no authenticated session to the target service is required; the attacker needs only the ability to submit a CMS payload. Applications that have already explicitly set the org.bouncycastle.gcm.allow_short_tags=false system property prior to this patch may have partial protection depending on library version.

The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N) signals high integrity impact with no authentication, no complexity barrier, and no user interaction required - a strong paper score. However, real-world exploitation requires an attacker to both craft a validly-structured CMS AuthEnvelopedData message (including correct key wrapping for the target recipient's key material) and deliver it to an application that processes such messages. This narrows the realistic attack surface to applications that actively receive and decrypt CMS AuthEnvelopedData payloads from untrusted or semi-trusted sources, such as secure messaging gateways, document exchange platforms, or PKCS#7-based workflows. There is no CISA KEV entry and no public POC, which tempers urgency relative to the raw score. EPSS data was not provided; exploitation is assessed as technically non-trivial but theoretically sound. A critical nuance: the upstream fix does NOT harden existing code by default - upgrading the library alone leaves applications vulnerable unless they also adopt the new setMinimumTagSize() API, meaning remediation requires both a library update and application-level code changes.

An attacker targeting a Java-based secure document exchange platform that accepts inbound CMS AuthEnvelopedData payloads crafts a malicious message encrypted for the target recipient's public key but specifying a 32-bit AES-GCM ICV in the AlgorithmIdentifier. The vulnerable Bouncy Castle recipient decrypts the message without validating the tag length, accepting the weakened authentication guarantee. With a 32-bit tag, the attacker can attempt ~4 billion forgeries to produce an ICV collision and deliver content that the application treats as authentically encrypted and unmodified. No public exploit code has been identified at time of analysis.