CVE-2026-103601 in bc-csharp
Summary
by MITRE • 10/02/2026
Release of unverified plaintext in the CCM (CcmBlockCipher) and DSTU 7624 CCM (KCcmBlockCipher) AEAD modes in Legion of the Bouncy Castle Inc. bc-csharp before 2.7.0 allows a remote attacker to obtain decryptions of ciphertexts of their choosing via forged messages sent to an application that lets the output buffer of a failed decryption be observed, for example through buffer reuse or logging, because decryption wrote the recovered plaintext into the caller-supplied output buffer before checking the authentication tag and left it there when the check failed. Only decryption into a caller-supplied buffer is affected; methods that return a newly allocated array are not.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Legion of the Bouncy Castle Inc. bc-csharp versions prior to 2.7.0 represents a critical implementation flaw within the Authenticated Encryption with Associated Data AEAD modes, specifically affecting CCM and DSTU 7624 CCM cipher implementations. This issue stems from an incorrect ordering of operations during the decryption process where the cryptographic engine writes the recovered plaintext into the caller-supplied output buffer before verifying the integrity of the authentication tag. In a secure implementation, the authentication check must precede any exposure of decrypted data to ensure that only authentic ciphertexts result in usable plaintext being returned or stored. By reversing this sequence, the library inadvertently exposes intermediate state information that should remain internal and protected from external observation.
This architectural flaw creates a side-channel attack vector known as an oracle vulnerability, specifically categorized under CWE-312 Cleartext Storage of Sensitive Information when considering how data is handled in memory during failure states. An attacker who can interact with the application utilizing this cryptographic library may send forged or tampered ciphertexts designed to trigger authentication failures. Because the decryption routine populates the output buffer prior to tag validation, a failed verification does not clear or overwrite that buffer. Consequently, if the application reuses the same memory buffer for subsequent operations or logs partial outputs during error handling routines, fragments of decrypted plaintext from previous successful decryptions may be overwritten by garbage data while remnants of the current attempted decryption remain visible in adjacent memory regions or log entries.
The operational impact of this vulnerability is severe as it allows a remote attacker to perform chosen-ciphertext attacks against encrypted communications. By carefully crafting inputs and observing differences in application behavior, logging outputs, or buffer contents during error conditions, an adversary can gradually recover sensitive plaintext data without possessing the decryption key. This undermines the confidentiality guarantees provided by AES-CCM encryption protocols. The risk is particularly acute for applications that employ fixed-size buffers reused across multiple cryptographic operations or those with verbose debugging modes enabled in production environments where stack traces or exception logs might inadvertently expose memory contents associated with failed authentication attempts.
Mitigation strategies require immediate upgrading to bc-csharp version 2.7.0 or later, which corrects the internal logic by ensuring that authentication tags are verified before any plaintext is written to the output buffer. For applications unable to upgrade immediately due to dependency constraints, defensive coding practices must be implemented at the application layer. Developers should avoid reusing buffers for cryptographic operations without explicit zeroing after each use and ensure that error handling routines do not log or expose raw byte arrays resulting from failed decryption attempts. Additionally, implementing constant-time comparison algorithms for authentication tags can help mitigate timing-based side channels, although this does not fully address the memory exposure issue inherent in the library's design flaw until patched. Adher to industry standards such as NIST SP 800-38C which outlines proper usage of CCM mode emphasizes that integrity verification must be completed before any plaintext is made available to higher-level application logic.