-
Notifications
You must be signed in to change notification settings - Fork 604
CVE 2026 16000
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.
KCcmBlockCipher implements the CCM authenticated-encryption mode of the Ukrainian standard DSTU 7624, normally used with Dstu7624Engine (Kalyna). The mode starts its CBC-MAC with a block, G1, which binds the nonce, the message length and a flags byte into the authentication tag. The implementation only processed G1 while it handled associated data. When a message was encrypted or decrypted without associated data, the tag was a MAC of the plaintext alone, independent of the nonce and the message length. That case covers no associated text in AeadParameters, initialisation with ParametersWithIV, and no call to ProcessAadBytes.
An attacker who can observe messages protected this way, and who knows or can choose some of their plaintext, can therefore build new ciphertexts with valid tags that the receiving side accepts as authentic. This does not directly expose plaintext, but it removes the integrity protection the mode is meant to provide. Only applications that construct KCcmBlockCipher themselves are exposed: nothing else in BC C# .NET uses this class (CipherUtilities maps "CCM" to the NIST CcmBlockCipher), and messages that carry associated data were not affected.
BC C# .NET 2.7.0 always processes the G1 block and sets its associated-data flag according to whether associated data is present, so the tag depends on the nonce and message length in every case. There is no new setting. Because the tag computation changes for messages without associated data, such messages produced by earlier versions will not verify under 2.7.0. The same release also fixes several other KCCM defects, including a counter that did not carry and so made the keystream repeat every 256 blocks.
Earlier versions have no setting that prevents this, so upgrading is recommended. Where that is not immediately possible, always supply associated data with KCcmBlockCipher. It must be a non-empty multiple of the cipher block size, for example a fixed block identifying the protocol or context, and it changes the message format, so both the sending and the receiving side have to make the change together.
The corresponding issue in BC Java was fixed in BC Java 1.85 (CVE-2026-12803).
Fix Commits:
Credit: Discovered by Claude, Anthropic's AI assistant, and triaged by the Anthropic security team in collaboration with Anthropic Research.