Bouncy Castle Java CVE-2026-12816

Exploitation requires all three of the following to be simultaneously true: (1) the application uses Bouncy Castle IESEngine initialized without an ephemeral sender key - specifically the static-static initialization path where V.length == 0, typically when IESParameters is constructed without an encoding vector component; (2) stream-cipher mode is selected rather than block-cipher mode within IES; and (3) the attacker can observe at least one encryption of a known plaintext under the target static key pair where the observed plaintext is at least macKeyBytes longer than the message to be forged. What limits exploitation: applications using standard ECIES with an ephemeral sender key (V.length != 0) are completely unaffected since the K2-first split was already correct in that branch; block-cipher mode is also not affected; and the known-plaintext requirement is a non-trivial operational prerequisite. The CVSS 4.0 PR:N confirms no authentication is required at the library level, but the static-key mode selection and known-plaintext constraint together meaningfully narrow the realistic attacker surface beyond what AV:N/AC:L suggests.

The CVSS 4.0 score of 8.7 with AV:N/AC:L/AT:N/PR:N/UI:N reflects that no authentication or special attacker network position is required at the library level, but the assigned AT:N understates the practical prerequisites. Exploitation requires the application to have specifically chosen static-key IES stream mode - a non-default and narrowly used configuration - AND the attacker must observe at least one known-plaintext ciphertext under the target key pair of a message longer than the MAC key length. Applications using standard ECIES with an ephemeral sender key (the recommended and most common mode) are entirely unaffected, as the V.length != 0 code path used the correct K2-first split. No CISA KEV listing is present, no EPSS data was provided, and no public exploit code exists beyond the vendor's own regression test, indicating no confirmed active exploitation. Real-world risk is meaningful only for the narrow set of deployments using static-key IES stream encryption; for the broader Bouncy Castle user base this is a low-probability, specialized attack.

An attacker targeting a system that encrypts messages with Bouncy Castle IESEngine in static-key stream mode observes a single ciphertext C for a known plaintext M of length L (obtainable if the attacker can influence what gets encrypted, or if messages contain predictable content). By XOR-ing M and C, the attacker recovers the keystream block, which in the vulnerable layout embeds the MAC key K2 at bytes [L..L+macKeyLen]; the attacker then constructs a forged ciphertext for an arbitrary message shorter than L bytes, computes a valid HMAC tag using the recovered K2, and submits the forgery - which the recipient's IESEngine accepts as authentic. The vendor's fix commit includes a working proof-of-concept regression test (doForgeryTest in ECIESTest.java) demonstrating this end-to-end attack with a 64-bit MAC key.