SURIQ
The math behind a Bitcoin wallet is only as trustworthy as the randomness that seeds it. Get the entropy wrong and every guarantee above it falls apart, no matter how sound the cryptography looks on paper. For more than four years the Coldcard hardware wallet shipped firmware that got the entropy wrong, and on July 30 someone turned that mistake into roughly 1,367 stolen Bitcoin.
The blockchain-analytics firm Galaxy Research traced the coordinated drain back to a random-number weakness in Coldcard, the Bitcoin-only hardware wallet made by the Canadian company Coinkite. Researchers call the connection likely rather than proven, since no public report has yet rebuilt a specific victim's seed and matched it to a looted address. But the defect Coinkite has detailed in its own advisory accounts for the theft cleanly, and it is a failure defenders have watched play out before under other names.
The random number generator that was not random
The root cause is one build-time slip. Coldcard's firmware was compiled with the entropy-enable flag, MICROPY_HW_ENABLE_RNG, left at zero, and the guarding code in libngu tested only whether that macro was defined, never whether it was actually switched on. With the flag effectively off, seed creation drew from MicroPython's built-in Yasmarang routine, a deterministic software generator, in place of the chip's real hardware entropy. That software path was seeded a single time at boot from the microcontroller's serial value and a handful of timer readings, and it folded in nothing new afterward. Coinkite's own figures put the resulting seeds at roughly 40 bits of unpredictability on the Mk3 and about 72 on newer boards, far below the 128 bits a twelve-word BIP-39 seed is meant to carry. Forty bits is small enough to search exhaustively.
That shortfall is the entire attack. If you can narrow a device's serial value, its timer readings at seed time, and how many times the generator had already been called, you can replay its output on your own machine, compute every address those candidate seeds would produce, and look for matches that already hold coins on the public ledger. The physical device stays untouched. There is no malware and no phishing here, only a brute-force sweep over a space that should have been astronomically large and was not.
The air gap did not matter
Here is what the early coverage skated past. People buy a hardware wallet for physical isolation: keys are generated and held on a device that never touches the internet, so a remote attacker cannot reach them. That property held perfectly here and protected no one. The seeds were rebuilt entirely offline from public data, because the weakness lived in the numbers the device produced, not in any network path into it. The security control everyone paid for was orthogonal to the failure. An offline signer with a predictable seed is a sealed vault whose combination was printed on the outside.
Who is actually affected
Coinkite names the affected firmware by model. The two sources differ slightly on the low bound of the Mk2 and Mk3 range, somewhere in the 4.0 series through 4.1.9, so treat any seed generated on a 4.0.x or 4.1.x build as suspect. Fixed builds are 4.2.0 for the Mk2 and Mk3, 5.6.0 for the Mk4 and Mk5, and 1.5.0Q for the Q.
| Model | Affected firmware | Fixed in |
|---|---|---|
| Mk2 and Mk3 | 4.0.x through 4.1.9 | 4.2.0 |
| Mk4 and Mk5 | before 5.6.0 (Edge before 6.6.0X) | 5.6.0 |
| Q | before 1.5.0Q (Edge before 6.6.0QX) | 1.5.0Q |
The dividing line is not which device you own but when its seed was created. A seed assembled by hand from fifty or more independent dice throws never touched the firmware generator and sits outside this bug's reach. Everyone else who created a seed on the affected firmware should assume it is guessable. The right question is not "is my device patched" but "which firmware produced my seed, and with how many bits behind it."
Updating the firmware is the wrong first move
The reflex on any firmware flaw is to patch, and here patching does almost nothing for the money at risk. Coinkite pushed emergency firmware on July 31, roughly 30 hours after the drain started, but loading it cannot undo a seed the earlier build already produced. Import that same seed onto the fixed firmware and you reintroduce the same weak randomness. The only genuine remedy is to generate a brand-new seed on a patched device and move every coin to addresses derived from it.
This is the shape of problem we keep returning to: the patch shuts the door for next time and does nothing about what already walked out. A password reset does not evict a stolen MFA seed, and a SharePoint update does not rotate the machine keys an attacker copied. Compromised key material has to be replaced, not patched around. For Coldcard owners that means a new seed and a fund migration. Adding a strong, one-off passphrase on top of the seed spins up a distinct wallet, but Coinkite still advises swapping the seed itself, and a multisig arrangement helps only when its signing keys are not all held on affected units.
You cannot detect a weak seed, only its consequences
There is no on-device symptom to hunt for. A low-entropy seed signs transactions exactly like a strong one, produces valid addresses, and behaves normally right up until someone sweeps it. The first observable event is the theft itself. In the opening ten minutes the attackers pulled about $30 million; by the 41-minute mark on July 30 they had emptied 1,196 addresses of 1,082.65 BTC, around $70.2 million at the time, and later waves widened the damage to roughly 4,585 addresses and $88.6 million. By the time there is anything to detect, the coins are gone. That is why the answer here is proactive migration, not monitoring. This kind of instant, no-alarm drain is the same reason a clipboard-swapping crypto worm is so hard to catch: the loss is the first signal.
The bug class that keeps shipping
A silent fallback from a hardware entropy source to a weak pseudorandom generator is not a new failure. In 2008 a Debian packaging change crippled OpenSSL's randomness and made years of SSH and TLS keys guessable. In 2013 an Android SecureRandom weakness let thieves lift Bitcoin from wallets generated on affected phones. Each time the cryptography was sound and the entropy under it was not, and each time the defect hid in plain sight, because weak randomness looks identical to strong randomness until someone tests it. Coldcard's macro that checked existence instead of value is a textbook instance of the same class.
The lesson reaches past crypto wallets. Any system that generates key material is trusting a random source at that moment, and that trust is rarely verified. Server operators meet the same trap when a virtual machine or container mints TLS or SSH host keys during early boot, before the kernel's entropy pool has filled. Key generation is the one operation where you cannot afford to assume the randomness is real. Where you can, mix in your own entropy. Where you cannot, treat any key born on a suspect source as burned and rotate it. This is also why a patch is rarely the finish line once secrets may already be exposed.
A hardware wallet moves the trust boundary into a black box and asks you to believe its randomness. Coldcard's holders believed it for four years. The takeaway is not that hardware wallets are bad. It is that a device you cannot audit is only as strong as the entropy you cannot see, and when that entropy is in doubt the only safe assumption is that the keys are already known.