CVE-2026-68765: hashcat KeePass Module Buffer Overflow

CVE-2026-68765 Overview

CVE-2026-68765 is a heap buffer overflow vulnerability [CWE-122] in hashcat master branch builds after version 7.1.2. The flaw resides in the KeePass AESKDF/KDBX v4 module (module_34301). The parser accepts up to 600 hex characters for the ninth token field but decodes it into a fixed 256-byte buffer without a length check. A maximal input writes up to 44 bytes past the buffer boundary into adjacent esalt fields and heap chunk metadata.

Critical Impact
A crafted KDBX v4 hash file processed by hashcat can corrupt adjacent heap memory, causing memory access violations or potential heap corruption in the cracking process.

Affected Products

hashcat master branch builds after v7.1.2
KeePass AESKDF/KDBX v4 module (module_34301)
Systems running vulnerable hashcat builds locally for password recovery

Discovery Timeline

2026-08-17 - CVE-2026-68765 published to NVD
2026-08-21 - Last updated in NVD database

Technical Details for CVE-2026-68765

Vulnerability Analysis

The vulnerability exists in src/modules/module_34301.c, which parses KeePass KDBX v4 hash strings for GPU-accelerated cracking. Hash strings are tokenized using * as a separator, and token nine represents the KDBX header data as hex-encoded bytes. The module declared token.len_max[9] = 600, allowing 600 hex characters (300 bytes decoded). The destination buffer inside the esalt structure is only 256 bytes. Decoding a maximal input overwrites 44 bytes beyond the buffer into adjacent esalt fields and glibc heap chunk metadata.

Exploitation requires local access with high privileges and user interaction, since an operator must run hashcat against an attacker-supplied hash file. The overflow primarily impacts availability but can also produce limited integrity effects on adjacent parsed state.

Root Cause

The root cause is missing bounds validation between the token length declaration and the fixed-size decode destination. The TOKEN_ATTR_VERIFY_LENGTH attribute enforced only the declared maximum of 600 hex characters, which was inconsistent with the underlying keepass4->header buffer size of 256 bytes. No secondary length check gated the hex-to-binary decode.

Attack Vector

An attacker crafts a KDBX v4 hash line where the ninth field contains close to 600 hex characters. When a local user loads this file with hashcat and selects mode 34301, the parser accepts the oversized token and decodes it into the undersized header buffer. The write extends 44 bytes past the allocation into adjacent esalt members and heap chunk metadata, producing memory corruption at parse time.

 // 9. header
 token.len_min[9] = 400;
-  token.len_max[9] = 600;
+  token.len_max[9] = 512; // sizeof (keepass4->header) * 2
 token.sep[9]     = '*';
 token.attr[9]    = TOKEN_ATTR_VERIFY_LENGTH | TOKEN_ATTR_VERIFY_HEX;

Source: GitHub Commit 6f374c4. The patch reduces len_max[9] to 512 hex characters, matching twice the size of the destination header buffer.

Detection Methods for CVE-2026-68765

Indicators of Compromise

hashcat processes crashing with SIGSEGV or glibc malloc corruption messages when parsing mode 34301 inputs
KDBX v4 hash files containing ninth-token fields longer than 512 hex characters
Unexpected termination of hashcat sessions during hash file load rather than during kernel execution

Detection Strategies

Inspect hashcat hash files for mode 34301 entries and validate that the ninth *-delimited field does not exceed 512 hex characters
Monitor for hashcat binaries built from master branch commits after v7.1.2 and prior to commit 6f374c4
Enable AddressSanitizer builds in test environments to catch heap-buffer-overflow reports originating in module_34301.c

Monitoring Recommendations

Log invocations of hashcat with -m 34301 and capture the source of input hash files
Correlate hashcat crash events with the hash file path to identify tampered or untrusted inputs
Track deployments of hashcat across analyst workstations and pin builds to reviewed commits

How to Mitigate CVE-2026-68765

Immediate Actions Required

Update hashcat to a build that includes commit 6f374c4ff7d5dc951530fbbbcf6b45e3c169b100 from Pull Request #4755
Rebuild any custom hashcat forks against the fixed module_34301.c
Restrict processing of KDBX v4 hash files to inputs from trusted sources only

Patch Information

The upstream fix lowers token.len_max[9] from 600 to 512 hex characters in src/modules/module_34301.c, aligning the maximum accepted token length with sizeof(keepass4->header) * 2. Refer to the VulnCheck Hashcat Advisory and the GitHub Hashcat Repository for release status.

Workarounds

Avoid using mode 34301 until a patched build is deployed
Pre-validate ninth-token length in KDBX v4 hash files with a wrapper script before invoking hashcat
Run hashcat in a restricted user context to limit blast radius of any parser-triggered memory corruption

bash

# Verify hashcat build includes the fix
git -C hashcat log --oneline | grep 6f374c4

# Reject KDBX v4 hash lines with an oversized ninth field
awk -F'*' 'length($10) > 512 {print "oversized token in line " NR; exit 1}' hashes.txt