Hashcat 7.1.2 Has Three Unpatched Vulnerabilities That Can Compromise Your Machine

Hashcat v7.1.2 has three unpatched vulnerabilities, all rated 9.8 out of 10. The tool that security professionals use to crack passwords can be used to crack the machine running it. The CVEs landed on May 1, 2026. There is still no patch.

Hashcat is the standard tool for recovering passwords from hashes. A hash is what a password looks like after a one-way scrambling algorithm runs over it. When a database leaks, the passwords do not come out as readable text. They come out as hashes, long strings of letters and numbers that look like gibberish. Hashcat works backwards. It takes guesses, runs the same algorithm over them, and checks whether the result matches a hash in the list. A single RTX 4090 can run through nearly 300 billion of those checks every second for the NTLM hash type used across Windows corporate networks. The tool has won the KoreLogic “Crack Me If You Can” 562901440119f978aa2b3ed1c1b6439a competition at DEF CON multiple times. Turns out, you can.

A security researcher audited the hashcat v7.1.2 source code in early April 2026 and found six security issues across three different areas. Three of them rated 9.8. A public issue landed on the hashcat GitHub repository on April 10. Seven days passed without a fix. Then everything went public.

A buffer overflow is what happens when a program writes more data into a slot in memory than that slot was built to hold. The data does not just disappear. It lands in the memory sitting right next to it, memory that belongs to other parts of the program. In the right situation, an attacker who controls what overflows that boundary can use it to make the program execute code it was never meant to run. All three vulnerabilities in hashcat work this way.

The first one sits in the rule engine, and it is tracked as CVE-2026-42482. Rules in hashcat are transformation instructions that modify password candidates before testing them. Instead of just trying “password”, the rule engine tries “Password”, “p4ssword”, “PASSWORD1”, and thousands of other variations automatically. One of those transformations converts a candidate into hexadecimal, which is how computers write data internally. Every character gets encoded as a two-character code: A becomes 41, Z becomes 5A, and the word “hash” becomes 68 61 73 68.

The bug is one missed calculation inside a function called mangle_to_hex_lower in the source file src/rp_cpu.c. The code checks whether the candidate fits in the output slot, but it did not account for the fact that hexadecimal encoding doubles the length. The output buffer holds 256 bytes. The guard only blocks inputs that are already 256 characters long, but never checks whether the input is too long after doubling. A candidate of 128 characters becomes 256 after conversion, and the loop starts writing at position 129, putting the first write at byte 258 and 259, both outside the buffer. Tested with ASAN, the memory error detector built into compilers, and reproduced 20 out of 20 times.

1
2
3

ERROR: AddressSanitizer: stack-buffer-overflow WRITE of size 1
    #0 in mangle_to_hex_lower src/rp_cpu.c:20
[32, 288) 'rule_buf_out' <== Memory access at offset 291 overflows this variable

A one-line fix has been sitting on GitHub as an open pull request since January 30, 2026. Three months passed. It was never merged.

Rule files like best64.rule, OneRuleToRuleThemAll and dive.rule are all over the place. A rule file is a plain text file with one transformation per line. If someone plants a crafted rule in one of those files, or puts up a convincing fake, the overflow fires the moment hashcat loads it. The flags -j and -k trigger the same bug directly from the command line when candidates are long enough. The session looks completely normal. Nothing signals that something is going wrong.

The source code is public. Anyone can read src/rp_cpu.c on GitHub and see exactly where the bug is, and exactly what the fix looks like, because that too is public.

The second vulnerability, CVE-2026-42483, is harder to shake off once you understand how it can be used. Kerberos is the authentication system that Microsoft Active Directory relies on internally. When you log into a Windows domain, Kerberos issues encrypted tickets that prove your identity to services across the network. A post-exploitation technique called Kerberoasting requests those service tickets from Active Directory using any regular domain user account, saves them as hash files, and lets you crack them at home on your own hardware with no connection to the target network needed. It is one of the first moves a penetration tester makes after getting a foothold on a Windows domain.

The workflow is straightforward. You get a domain user account, run Impacket’s GetUserSPNs.py or Rubeus, pull the service tickets, save them to a file, copy that file to your own machine, and start hashcat. That last step is where the exposure sits.

The bug lives in a function called module_hash_decode, and it affects twelve separate Kerberos-related hash modules. When hashcat parses a Kerberos hash file, it calculates how much data to copy by reading the positions of separator characters inside the hash string. Those separators come from the file. Whoever controls the file controls where those separators are, and by doing that controls how much data gets copied. That number gets handed directly to memcpy, a raw memory copy function, with nothing checking whether it actually fits in the destination buffer called account_info. The data overflows into the heap, the part of memory programs use to hold data they need to keep while running.

Unlike the rule engine overflow, the bytes written in this one are not limited to hex characters. An attacker has more control over what lands in that overflow, which matters when assessing how exploitable this actually is.

The person doing the attacking becomes the target.

The third vulnerability, CVE-2026-42484, is in the PKZIP hash parser. Cracking password-protected ZIP archives is a routine task in security assessments and CTF competitions. You find an encrypted archive, extract the hash with zip2john, and hand it to hashcat. The vulnerability affects five modules: 17200, 17210, 17220, 17225, and 17230. When the hash line has data_type set to 1 or lower, the parser skips the length check that would normally catch an oversized input. The hex data field gets decoded directly into a 320 kilobyte fixed buffer without any validation of how long that data actually is. A crafted hash line with data_type=1 and an oversized hex field triggers it every time.

It is worth being precise about what the CVSS 9.8 rating means and what it does not mean. The researcher who found these vulnerabilities tested the rule engine overflow against a default build with stack canary protections enabled, as shipped by Fedora and Ubuntu. Code execution was not achieved. The overflow writes only hex characters, which limits what can land in adjacent memory, and the stack canary needs to be bypassed before a return address can be controlled. What was confirmed, every time, was a reliable crash. That is already significant for anyone running hashcat in an automated pipeline, but it is not the same as confirmed remote code execution.

There is no patch. The CVEs published on May 1, 2026, and hashcat v7.1.2 is still the current release at the time of writing. Pull request #4618, which fixes the rule engine bug, has been open since January 30 and remains unmerged.

To check which version is on your machine:

1

hashcat --version

If the output shows v7.1.2, all three vulnerabilities are present.

What to do right now. Until a patched release ships, avoid loading hash files from sources you do not fully control without isolating the process first. Running hashcat inside a virtual machine or container means that if something goes wrong during parsing, it stays contained and cannot touch the host system. Rule files downloaded from GitHub or shared in community channels should be treated the same as any other executable input, because in this context that is effectively what they are. If you run automated cracking pipelines that pull hash files or rule files from shared storage or external sources, this applies to those too.

You can follow the status of the fix directly on GitHub at hashcat/hashcat issue #4664 and pull request #4618. When a patched version is released, update immediately.

Three unpatched CVSS 9.8 vulnerabilities. A fix sitting on GitHub for three months without being merged. The source code public and readable by anyone. The tool on virtually every pentester’s machine. The question is not whether someone will build something with this. It is when.

How to use hashcat in real post-exploitation scenarios, how to dump and crack credentials from compromised systems, and how privilege escalation actually works step by step are exactly what the ethical hacking course covers:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life. 🎯

Sources: NVD — CVE-2026-42482 | Full disclosure — sgInnora