CVE-2026-68765 in Hashcat
Summary
by MITRE • 08/17/2026
hashcat master branch builds after v7.1.2 contain a heap buffer overflow vulnerability in the KeePass AESKDF/KDBX v4 module (module 34301) that allows attackers to corrupt adjacent heap memory by supplying an oversized ninth hash field token. The module accepts up to 600 hex characters for the ninth token field but decodes it into a fixed 256-byte buffer with no length check, allowing a maximal input to write up to 44 bytes past the buffer boundary into adjacent esalt fields and heap chunk metadata, potentially enabling heap corruption or memory access violations.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/17/2026
The vulnerability identified in hashcat versions following v7.1.2 represents a critical security flaw within the KeePass AESKDF/KDBX v4 module, specifically designated as module 34301. This component is responsible for processing password hashes associated with KeePass database files that utilize version four encryption standards. The core of the issue lies in the input validation logic governing the ninth hash field token during the decryption process. While the application interface permits users to supply up to six hundred hexadecimal characters for this specific field, the underlying C implementation allocates a fixed-size buffer of only two hundred and fifty-six bytes to store the decoded binary data. This discrepancy between the accepted input length and the allocated memory size creates a classic heap buffer overflow condition that can be triggered by an attacker providing a maliciously crafted hash string exceeding the safe decoding limit.
From a technical perspective, the flaw stems from a missing boundary check during the hex-to-binary conversion routine. When the ninth token field contains more than one hundred twenty-eight hexadecimal characters, which corresponds to two hundred and fifty-six bytes of binary data, any additional input results in writes beyond the allocated buffer's upper bound. Because this operation occurs on the heap rather than the stack, the overflow does not merely overwrite local variables but corrupts adjacent memory structures. Specifically, the excess data spills into neighboring esalt fields and critical heap chunk metadata. This corruption can lead to unpredictable application behavior, including segmentation faults due to memory access violations or more severe outcomes such as arbitrary code execution if an attacker can precisely control the overwritten metadata to manipulate heap allocation pointers.
The operational impact of this vulnerability is significant for users who process untrusted KeePass hash files. An adversary could craft a malicious KDBX v4 file containing a specially designed ninth token that, when processed by a vulnerable version of hashcat, triggers the buffer overflow. Depending on the memory layout and execution context, this could allow an attacker to read sensitive information from adjacent heap regions or execute arbitrary code with the privileges of the user running the application. This aligns closely with CWE-122, which describes heap-based buffer overflows where data is written past the end of a heap allocated buffer. Furthermore, in the context of attack techniques, this vulnerability facilitates exploitation vectors similar to those described under ATT&CK technique T1059, as it involves executing code through memory corruption mechanisms that bypass standard security controls by exploiting improper input validation and boundary checks within application logic.
Mitigation strategies for this issue primarily involve updating hashcat to a version where the patch has been applied, ensuring that proper length validation is enforced before decoding hex strings into binary buffers. For environments where immediate updates are not feasible, administrators should restrict the use of module 34301 to trusted inputs only and avoid processing KeePass hashes from unverified sources. Additionally, enabling heap protection mechanisms such as Address Space Layout Randomization (ASLR) can help mitigate exploitation by making it more difficult for attackers to predict memory addresses required for successful code execution. Developers should also implement rigorous input sanitization practices that strictly enforce maximum length constraints corresponding to the allocated buffer size before any decoding operations take place, thereby preventing overflow conditions at the source rather than relying on runtime protections alone.