Bouncy Castle C# CVE-2026-15999

Exploitation requires an on-path (man-in-the-middle) attacker able to intercept and modify CMS EnvelopedData messages encrypted with AES-CCM (or AES-GCM), AND a victim application using vulnerable bc-csharp (before 2.7.0) to decrypt that content via CmsEnvelopedData/CmsEnvelopedDataParser or any caller passing an unchecked tag length into CcmBlockCipher for decryption. The concrete trigger is an attacker-supplied AlgorithmIdentifier whose CCMParameters set aes-ICVlen to zero or a value outside the RFC 5084 set {4,6,8,10,12,14,16}, which the pre-patch CcmParameters accepted unchecked. LIMITING FACTORS: the attacker must already hold a network interception position (no remote-from-anywhere access - hence AT:P); the flaw affects only the AEAD CCM/GCM CMS decryption paths, not all cipher usage; and the application must process the attacker-influenced AlgorithmIdentifier during decryption. No authentication is required (PR:N) and no user interaction is needed (UI:N).

This is a genuine integrity/tampering vulnerability rather than a high-CVSS paper tiger, but its exploitability is gated by a demanding precondition. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N, 8.2) is internally consistent with the description: the sole impact is integrity (VI:H), with no confidentiality (VC:N) or availability (VA:N) effect, and the AT:P 'attack requirements present' flag correctly reflects that the attacker must occupy an on-path/man-in-the-middle position to modify CCM-encrypted CMS content in transit. The high VI:H score is justified because defeating the AEAD authentication tag silently breaks the core guarantee of authenticated encryption - modified ciphertext decrypts as if valid. However, several real-world-risk signals temper this: EPSS is not provided, the vulnerability is NOT in CISA KEV, and no public exploit (POC) is indicated, so there is no evidence of active or opportunistic exploitation. Crucially, exploitation is not 'spray-and-pray' - it requires both an on-path adversary AND a victim application that decrypts attacker-influenced AES-CCM (or GCM) CMS EnvelopedData using the vulnerable bc-csharp paths. Note a tag/impact conflict: the input Tags label this 'Information Disclosure,' which directly contradicts the CVSS confidentiality metric (VC:N) - this is an integrity/tampering flaw, not a disclosure flaw. Net assessment: a credible, vendor-confirmed and patched cryptographic weakness worth prioritizing for any .NET application performing AES-CCM CMS decryption on untrusted input, but not an emergency mass-exploitation threat given the on-path requirement and absence of KEV/POC signals.

An on-path attacker intercepting CMS EnvelopedData protected with AES-CCM crafts an AlgorithmIdentifier whose CCMParameters declare an authentication tag length (aes-ICVlen) of zero or another length outside the RFC 5084 set. Because CcmParameters accepted any value and CcmBlockCipher only validated tag length on encryption, the victim's bc-csharp decryption (via CmsEnvelopedData/CmsEnvelopedDataParser and ParameterUtilities.GetCipherParameters) compares against a zero-length or truncated tag, allowing the attacker to silently alter the encrypted payload without detection. No public exploit code is identified at time of analysis, and exploitation requires the attacker to already hold an on-path position.