hashcat EUVD-2026-64311

The victim must run 'hashcat --restore' (or the legacy one-step equivalent) against a restore file that has been crafted or modified by an attacker prior to the session resumption. The restore file must reside on the local filesystem accessible to the hashcat process; the attack vector is strictly local (AV:L per CVSS 4.0) and the attacker cannot interact with hashcat directly. Delivery of the malicious restore file requires a separate attack path such as social engineering, a writeable shared network mount, or compromise of an upstream session file store. Exploitation is further gated by the requirement that the victim actively choose to restore a session (UI:P in CVSS 4.0). The vulnerability has no effect during normal hashcat cracking operations that do not use the --restore feature, and it does not allow remote unauthenticated exploitation in any configuration.

CVSS 4.0 scores this at 8.5 with a local attack vector (AV:L), low complexity (AC:L), no privilege requirement on the attacker's part (PR:N), and passive user interaction (UI:P), reflecting that exploitation is contingent on the victim actively running hashcat against a tampered restore file. The high VC/VI/VA ratings are justified - writing to shell startup files achieves persistent code execution at the user level, with potential privilege escalation if the affected account has elevated rights. No EPSS score was provided in the input data, and this CVE is not listed in CISA KEV, so breadth of active exploitation is unconfirmed. The realistic threat actor must first deliver the malicious restore file through a separate channel - social engineering, a shared network path, or a poisoned upstream session file store - which substantially raises the bar for opportunistic mass exploitation. The local-only, user-interaction-dependent nature of the attack means that security teams running shared hashcat environments with collaborative session files represent a meaningfully elevated risk group and should prioritize patching over teams where restore files are never shared. The absence of a confirmed exploit and KEV listing suggests targeted rather than widespread exploitation at this time.

An attacker places a crafted hashcat restore file containing injected options such as '--outfile /home/victim/.bashrc' and attacker-controlled payload content on a shared NFS mount used by a red team or delivers it via social engineering. When the victim runs 'hashcat --restore' referencing this file, hashcat appends the attacker-supplied content to ~/.bashrc. On the victim's next login, the injected shell commands execute with the victim's privileges, achieving persistent code execution.