Skip to content

CVE 2026 63567

Peter Dettman edited this page Oct 1, 2026 · 1 revision

CVE-2026-63567

Issue affecting: BC C# .NET 2.6.2 and earlier, and the 2.7.0-beta.98 pre-release.

Fixed versions: BC C# .NET 2.7.0

Platform affected: All CLRs.

When IesEngine is constructed with a block cipher (the constructor that takes a BufferedBlockCipher), decryption ran the cipher to completion, including removal of the padding, before computing and checking the MAC over the ciphertext. With a padded cipher such as AES in CBC mode with PKCS#7 padding, a ciphertext with bad padding was rejected with a "pad block corrupted" error and without the MAC being computed, while one with good padding but a bad MAC was rejected with "Invalid MAC.".

An application is exposed if it uses IesEngine in this mode to decrypt ciphertexts from an untrusted party under a fixed key pair, and that party can tell the two failures apart, from the error reported or from the time taken. The party can then use the application as a padding oracle and, by submitting many modified ciphertexts, recover the plaintext of an IES or ECIES message it has captured, without the private key. IesEngine in stream mode (no block cipher), which is also what the "IES" and "ECIES" names in CipherUtilities use, is not affected by this issue.

BC C# .NET 2.7.0 verifies the MAC over the ciphertext before the final block is decrypted and the padding removed, so a ciphertext that fails authentication is always rejected with "Invalid MAC." and padding is only examined once the input has been authenticated. The ciphertext format in block-cipher mode is unchanged, so messages encrypted with earlier versions still decrypt.

Users of earlier versions who cannot upgrade can give the decrypting IesEngine the same CBC cipher in a BufferedBlockCipher without padding, and strip the PKCS#7 padding from the result themselves after ProcessBlock returns, by which point the MAC has been verified; this still decrypts ciphertexts produced by a padded encryptor. Applications should in any case report every decryption failure in the same way.

BC Java fixed the equivalent issue in its IESEngine in BC Java 1.56 (CVE-2016-1000345).

Fix Commits:

Credit: Discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.

Clone this wiki locally