CVE-2026-118767 in Botan
Summary
by MITRE • 10/29/2026
Botan is a C++ cryptography library. From 1.11.22 until 3.13.0, Botan's Python binding converted Python strings containing U+0000 to const char* values without consistently rejecting the embedded NUL, causing bcrypt and check_bcrypt to process only the prefix before the NUL. Applications could validate a longer password but hash a shorter effective value, allowing application password-policy bypass; scrypt and argon2 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 vulnerability identified within the Botan cryptography library represents a critical flaw in its Python binding implementation regarding string handling during cryptographic hashing operations. Specifically, between versions 1.11.22 and 3.13.0, the conversion mechanism for transforming Python strings into C-style character arrays failed to consistently reject embedded NUL characters, represented as U+0000. In standard C programming practices, a string is terminated by a null byte, meaning that any data following this byte is typically ignored during processing functions such as strlen or direct memory reads in hashing algorithms. This architectural assumption was not adequately guarded against when interfacing with Python's more flexible Unicode string model, which allows for embedded NULs within the same object. Consequently, when passwords containing these hidden null bytes were passed to cryptographic hash functions like bcrypt and check_bcrypt, the library processed only the substring preceding the first NUL character. This discrepancy creates a significant divergence between the logical input provided by the application developer or user and the actual data consumed by the underlying C++ implementation of the hashing algorithm.
The operational impact of this flaw is severe in contexts where password validation relies on consistent string processing across different layers of an application stack. An attacker who can control the input to a system using these vulnerable versions of Botan could intentionally append a NUL character followed by additional complex characters to their chosen password. For instance, if a user sets a password like "password123\x00!@#$%^&*", the bcrypt function would only hash and store the prefix "password123". If an application's policy checks for complexity or length against the full input string including the suffix after the NUL, it might deem the password compliant. However, during authentication attempts where the same logic applies, if the attacker simply provides "password123" without the trailing garbage and null byte, they would successfully authenticate because the stored hash corresponds to that shorter prefix. This effectively allows for a bypass of application-level password policies designed to enforce minimum length or complexity requirements, as the effective secret used for verification is significantly weaker than what was ostensibly validated during account creation.
It is important to note that this vulnerability does not affect all cryptographic primitives supported by Botan. The scrypt and argon2 implementations remain unaffected because they likely utilize different string handling mechanisms or are implemented in a way that respects Python's Unicode semantics without truncation at NUL boundaries. This selective impact highlights the importance of auditing specific bindings rather than assuming uniform behavior across an entire library suite. The root cause lies in the unsafe conversion practices within the Python binding layer, which prioritizes performance or simplicity over strict input validation for null-terminated string expectations inherent to C APIs.
To mitigate this vulnerability and prevent similar issues in future implementations, it is essential to enforce strict input sanitization at the boundary between high-level languages like Python and low-level systems code written in C++. Developers should explicitly validate that strings do not contain embedded NUL characters before passing them to cryptographic functions that expect null-terminated inputs. Alternatively, using explicit length parameters for string operations rather than relying on implicit termination can prevent truncation issues. For organizations currently running vulnerable versions of Botan, upgrading to version 3.13.0 or later is the primary remediation step as this release addresses the inconsistent rejection of embedded NUL characters. Additionally, security teams should review applications that rely on bcrypt for password storage to ensure no legacy data was created with truncated hashes due to this flaw, potentially requiring a forced password reset for affected users if there is evidence of exploitation or policy bypass in production environments. This incident underscores the critical need for rigorous boundary checking when integrating cryptographic libraries into higher-level application logic, aligning with CWE-170 Improper Null Termination and ATT&CK techniques related to credential access and defense evasion through input manipulation.