Bouncy Castle C# CVE-2026-16001

Exploitation requires a very specific configuration: IesEngine must be constructed WITHOUT a block cipher (stream mode) AND initialized in static-static mode - the Init entry point that supplies static keys on both sides with no ephemeral sender component (the patch's security note confirms this makes encryption effectively deterministic). The attacker must additionally have observed at least one genuine encrypted message AND know its plaintext to recover the keystream. Forgery is LIMITED to messages strictly shorter than the observed message, since only that portion of the keystream (and thus the MAC key) is revealed. Applications using the standard ECIES mode with ephemeral sender keys, or stream mode with a block cipher, are not affected. These constraints (AT:P, shorter-message-only, known-plaintext requirement) meaningfully narrow realistic exploitation despite the network, unauthenticated vector.

This is a genuine cryptographic integrity flaw rather than an inflated high-CVSS issue, but its real-world priority is constrained by a narrow precondition set. The vendor-assigned CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) scores 8.2 with VI:H and crucially VC:N/VA:N - the impact is message forgery/integrity loss, not confidentiality or availability. The AT:P (attack requirements present) metric correctly captures that exploitation is not trivial: the attacker must first observe a legitimate encrypted message AND know its plaintext, and can only forge messages strictly shorter than that observed message. No EPSS score was provided, there is no CISA KEV listing, and no public exploit code was referenced, so exploitation status is 'no public exploit identified at time of analysis.' The flaw was reported by the vendor itself (bcorg) and a patch is available, indicating responsible coordinated disclosure rather than active in-the-wild abuse. One signal worth flagging: the input Tags label this 'Information Disclosure,' which conflicts with the CVSS impact profile (VC:N, VI:H) and CWE-354 (improper validation of integrity check value) - the true impact is authentication forgery, not confidentiality loss. Overall this is a real, verify-and-patch-level issue for the specific vulnerable configuration, not an emergency for the typical BouncyCastle deployment.

An attacker passively captures one ciphertext produced by an application using IesEngine in stream mode (no block cipher) with a static-static key configuration, and happens to know that message's plaintext. Because the MAC key is drawn from the key-derivation output immediately after a keystream only as long as the message, the captured keystream reveals the MAC key for any shorter message, letting the attacker craft a bogus ciphertext plus a valid MAC tag that the recipient accepts as authentic. No public proof-of-concept was referenced, and the attack is network-reachable (AV:N) with low computational complexity but requires the known-plaintext precondition (AT:P).