Same hash type, same password, multiple hashes cracked???

[Infortunate]

As you can see below, I'm getting the same password cracked with 2 different hashes (from unsalted SHA1, workload 100). How is it possible? :

.\hashcat.exe -m 100 -a 3 -w 3 --potfile-disable d3452821155680b012da42b4fe11a90981a81aae shabang!
hashcat (v6.2.6) starting

* Device #1: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #2: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
CUDA API (CUDA 13.0)
====================
* Device #1: NVIDIA GeForce RTX 4070 SUPER, 11051/12281 MB, 56MCU

OpenCL API (OpenCL 3.0 CUDA 13.0.97) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #2: NVIDIA GeForce RTX 4070 SUPER, skipped

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1475 MB

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

d3452821155680b012da42b4fe11a90981a81aaehabang!

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 100 (SHA1)
Hash.Target......: d3452821155680b012da42b4fe11a90981a81aae
Time.Started.....: Mon Aug 17 15:42:14 2026 (0 secs)
Time.Estimated...: Mon Aug 17 15:42:14 2026 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: shabang! [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:    6532 H/s (0.01ms) @ Accel:256 Loops:1 Thr:128 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: shabang! -> shabang!
Hardware.Mon.#1..: Temp: 41c Fan: 30% Util:  2% Core:2475MHz Mem:10501MHz Bus:16

Started: Mon Aug 17 15:42:12 2026
Stopped: Mon Aug 17 15:42:15 2026
PS C:\Users\******\Desktop\hashcat-6.2.6> .\hashcat.exe -m 100 -a 3 -w 3 --potfile-disable 03452821155680b012da42b4fe11a90981a81aae shabang!
hashcat (v6.2.6) starting

* Device #1: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
* Device #2: WARNING! Kernel exec timeout is not disabled.
            This may cause "CL_OUT_OF_RESOURCES" or related errors.
            To disable the timeout, see: https://hashcat.net/q/timeoutpatch
CUDA API (CUDA 13.0)
====================
* Device #1: NVIDIA GeForce RTX 4070 SUPER, 11051/12281 MB, 56MCU

OpenCL API (OpenCL 3.0 CUDA 13.0.97) - Platform #1 [NVIDIA Corporation]
=======================================================================
* Device #2: NVIDIA GeForce RTX 4070 SUPER, skipped

Minimum password length supported by kernel: 0
Maximum password length supported by kernel: 256

Hashes: 1 digests; 1 unique digests, 1 unique salts
Bitmaps: 16 bits, 65536 entries, 0x0000ffff mask, 262144 bytes, 5/13 rotates

Optimizers applied:
* Zero-Byte
* Early-Skip
* Not-Salted
* Not-Iterated
* Single-Hash
* Single-Salt
* Brute-Force
* Raw-Hash

ATTENTION! Pure (unoptimized) backend kernels selected.
Pure kernels can crack longer passwords, but drastically reduce performance.
If you want to switch to optimized kernels, append -O to your commandline.
See the above message to find out about the exact limits.

Watchdog: Temperature abort trigger set to 90c

Host memory required for this attack: 1475 MB

The wordlist or mask that you are using is too small.
This means that hashcat cannot use the full parallel power of your device(s).
Unless you supply more work, your cracking speed will drop.
For tips on supplying more work, see: https://hashcat.net/faq/morework

Approaching final keyspace - workload adjusted.

03452821155680b012da42b4fe11a90981a81aaehabang!

Session..........: hashcat
Status...........: Cracked
Hash.Mode........: 100 (SHA1)
Hash.Target......: 03452821155680b012da42b4fe11a90981a81aae
Time.Started.....: Mon Aug 17 15:42:24 2026 (0 secs)
Time.Estimated...: Mon Aug 17 15:42:24 2026 (0 secs)
Kernel.Feature...: Pure Kernel
Guess.Mask.......: shabang! [8]
Guess.Queue......: 1/1 (100.00%)
Speed.#1.........:    4836 H/s (0.02ms) @ Accel:256 Loops:1 Thr:128 Vec:1
Recovered........: 1/1 (100.00%) Digests (total), 1/1 (100.00%) Digests (new)
Progress.........: 1/1 (100.00%)
Rejected.........: 0/1 (0.00%)
Restore.Point....: 0/1 (0.00%)
Restore.Sub.#1...: Salt:0 Amplifier:0-1 Iteration:0-1
Candidate.Engine.: Device Generator
Candidates.#1....: shabang! -> shabang!
Hardware.Mon.#1..: Temp: 41c Fan: 30% Util:  0% Core:2475MHz Mem:10501MHz Bus:16

Started: Mon Aug 17 15:42:22 2026
Stopped: Mon Aug 17 15:42:25 2026

[Infortunate]

For context, I found this while attempting to crack a large SHA1 list of hashes with dictionary attack. I cracked a few and went to validate them. But this one came out as not a match (the 03452821155680b012da42b4fe11a90981a81aae hash was the one in the file). I got confused (as this is the first time this happens to me), so for sanity check, I tried to generate the hash from the password that hashcat supposedly found (shabang!) and it generated d3452821155680b012da42b4fe11a90981a81aae (which is very similar except the for first character). I then tried to crack both hashes in hashcat and, low and behold, both cracked with the same password.

[nick8606]

Only 128 bits of hash are used for final comparison, even if hash is longer.
See Hashcat Plugin Development Guide.

P. S. Obviously, one of your hashes contains wrong symbol. Nevertheless, hashcat found correct password.

[Infortunate]

Thank you for your answer and link. From reading it, this part seems to relate to what you're saying: "Therefore it is safe to store only 128 bits of it in a lookup database in hashcat. That means even for SHA512 with 512 bits, we are actually only interested in 128 bits of it. That is great, so we only need to test for 128 bits instead of 512 bits and save some clocks."
So from this and other info from that link, am I right to understand that basically it is a freak accident where the 128 bits tested match the hash from my list except for that specific part that isnt tested and should match? If so then there is just no solution and the hash is just corrupted and not linked to any real password?
Or is there a way to test a different "position" of those 128 bits (that would include the different character)?

[Chick3nman]

Your two hashes appear to be:

d3452821155680b012da42b4fe11a90981a81aae
and
03452821155680b012da42b4fe11a90981a81aae

As you can tell, the only difference is that the first character is different. Because we only test 128 bits, and it happens that the first block is not part of that 128 bit window, we consider these to be the "same" hash. The chances of 2 SHA1 hashes sharing 128 bits (or in this case far more) and both being passwords within the same list are so incredibly small that we consider this behavior to be acceptable. If for some reason this were to happen in the real world, we could work around it, but this is extremely unlikely to cause problems in real world usage and it would be a pretty big deal if this were ever to happen.