hashcat CVE-2026-68768

Both --username and --show flags must be passed simultaneously to hashcat for the vulnerable code path in outfile_write() to execute. The attacker must supply or influence the hash file consumed by hashcat - either by delivering a crafted file directly or by positioning it where an analyst will process it. The CVSS UI:P metric confirms that the operator must actively invoke hashcat against the malicious file; there is no passive or background trigger. Exploitation is strictly local (AV:L): hashcat exposes no network interface, and remote exploitation is not possible. Default hashcat usage without --username, and crack-mode runs without --show, are unaffected. No privilege level is required to run hashcat itself, but the attacker's primary dependency is operator action against attacker-controlled input.

The CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N, score 6.9) accurately characterises this as a medium-severity local issue: attack vector is local, user interaction is required, and primary impact is availability (crash/memory corruption) with negligible confidentiality impact. The PR:N metric reflects that no authentication to a service is required, but this must not be misread as remotely exploitable - AV:L firmly bounds exploitation to the local system where hashcat is invoked. There is no CISA KEV listing and no identified public proof-of-concept, both of which substantially reduce real-world urgency. Because hashcat is an operator-invoked command-line tool rather than an always-on service, the attack surface is inherently narrow: exploitation requires an analyst to actively process a crafted file with specific flags. The risk is most relevant to red-team or forensic teams that routinely run hashcat --username --show against externally sourced hash dumps, where the origin of the file may not be fully trusted.

An attacker crafts a hash file containing a username field sized to nearly fill the 16 MB HCBUFSIZ_LARGE buffer. When a security analyst runs hashcat --username --show against this file as part of a routine password-audit workflow, outfile_write() copies the oversized username into the heap buffer and then appends the separator, hash, and plaintext without checking remaining space, overflowing the buffer, corrupting adjacent heap metadata, and crashing the process. No public proof-of-concept has been identified at time of analysis, but the trigger condition is straightforward to reproduce from the description and commit diff alone.