CVE-2026-118769 in Botan
Summary
by MITRE • 10/29/2026
Botan is a C++ cryptography library. From 2.1.0 until 3.13.0, the Botan C API function botan_block_cipher_block_size converted a size_t block size to int without a bounds check. In an application that accepts external algorithm parameter strings and uses the FFI raw ECB mode, an attacker can select the variable-block-size Lion cipher so that the reported size is truncated, the caller allocates insufficient memory, and later block processing causes memory corruption. The C++ API and normally used C API modes such as CBC and CTR are unaffected. This issue is fixed in version 3.13.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The Botan cryptography library, a widely utilized open-source C++ cryptographic toolkit, contains a critical integer truncation vulnerability within its C Application Programming Interface that can lead to memory corruption when specific algorithm parameters are manipulated by an attacker. This flaw exists in the botan_block_cipher_block_size function across versions from 2.1.0 through 3.13.0. The core technical issue stems from a lack of bounds checking during type conversion, where the function returns the block size as a signed integer rather than preserving its original unsigned long long or size_t representation. While most cryptographic operations rely on fixed-size blocks such as AES with a constant 128-bit length, this vulnerability specifically impacts variable-block-size ciphers like Lion, which was introduced in Botan to support formats like OCB and SIV that allow for flexible block sizes up to 64 bytes or more depending on configuration.
In typical usage scenarios involving the C++ API or standard C API modes such as CBC and CTR, this vulnerability remains dormant because these implementations either use fixed-size buffers internally or do not expose the raw block size in a manner that allows external manipulation of allocation sizes based on user-supplied algorithm strings. However, applications that accept external algorithm parameter strings and utilize the Foreign Function Interface to access raw ECB mode are exposed to significant risk. In this specific configuration, an attacker can inject a malicious payload specifying the Lion cipher with parameters that result in a block size exceeding 2147483647 bytes, which is the maximum value for a signed 32-bit integer. When botan_block_cipher_block_size processes this request, it truncates the large unsigned value into a negative or small positive signed integer due to overflow behavior inherent in C type conversions without explicit checks.
The operational impact of this vulnerability is severe, leading directly to heap-based buffer overflows and subsequent memory corruption. An application relying on the truncated block size will allocate an insufficient amount of memory for its internal buffers, assuming the block size is small based on the corrupted integer value. When cryptographic operations proceed using raw ECB mode with actual large blocks, the library attempts to write data into these undersized allocations. This mismatch between allocated and required memory results in out-of-bounds writes, which can corrupt adjacent heap metadata or overwrite critical application data structures. Such corruption typically leads to immediate application crashes causing denial of service, but more critically it creates opportunities for arbitrary code execution if an attacker can carefully craft the overflow payload to control instruction pointers or function return addresses within the process memory space.
This vulnerability aligns with Common Weakness Enumeration CWE-190, which describes integer overflow or wraparound errors that lead to subsequent security weaknesses such as buffer overflows. It also maps to MITRE ATT&CK technique T1203, Exploitation for Client Execution, if the vulnerable application is a client-side component processing untrusted input, and potentially T1496 Resource Hijacking in cases where denial of service is the primary outcome. The root cause lies in inadequate validation of external inputs before performing arithmetic operations or type conversions that affect resource allocation sizes. Developers integrating Botan must ensure they validate all algorithm parameters against known safe ranges before passing them to cryptographic functions, particularly when using raw modes like ECB which expose lower-level memory management details to the application layer.
Mitigation strategies primarily involve upgrading to version 3.13.0 or later of the Botan library where this integer truncation issue has been resolved with proper bounds checking during type conversion. For applications unable to upgrade immediately, defensive programming practices should be implemented by validating algorithm identifiers and block sizes against a whitelist of supported configurations before invoking cryptographic operations. Additionally, avoiding the use of raw ECB mode in favor of authenticated encryption modes like GCM or ChaCha20-Poly1305 reduces exposure since these higher-level abstractions handle memory allocation internally without exposing size calculations to external manipulation. Security audits should focus on identifying any custom FFI bindings that directly expose low-level block cipher functions, ensuring that all integer conversions from cryptographic libraries include explicit checks for overflow and underflow conditions consistent with secure coding standards such as OWASP Secure Coding Practices.