CRITICAL: Coldcard Seed Flaw Linked to $70 Million Bitcoin Theft

Cold storage was supposed to be the boring part of Bitcoin security. You buy a hardware wallet, you let it generate a seed phrase, you stamp that phrase into a steel plate, and you stop thinking about it. The entire value proposition is that the private key never touches an internet connected machine, so there is nothing to phish, nothing to drain, and nothing to lose short of somebody showing up at your door with a wrench.

On July 30, an attacker emptied 1,196 Bitcoin addresses in 41 minutes without going near a single device.

The take was 1,082.65 BTC, worth roughly $70.2 million at the time of the sweep. There was no malware, no phishing page, and no implant slipped into a shipping box. The attacker simply calculated the private keys, because for roughly five years Coldcard hardware wallets had been generating seed phrases that were never actually random.

The one line integration bug

Coldcard is built by Coinkite, a Canadian firm, and it is the Bitcoin only hardware wallet that the most security conscious corner of the market tends to recommend to everyone else. The devices run an STM32 microcontroller that includes a true hardware random number generator, which is exactly the component you want feeding seed generation. That hardware RNG is not what produced the seeds now at risk.

In March 2021, a firmware integration change introduced a build configuration error in libngu, the cryptographic library Coldcard relies on. The code checked whether the MICROPY_HW_ENABLE_RNG macro was defined rather than whether it was actually enabled. The macro existed, the check passed, and the build silently bound seed generation to MicroPython's Yasmarang fallback PRNG instead of the silicon sitting right there on the board.

Yasmarang is a deterministic software generator. In this build it was initialized from nothing more exotic than the chip UID and a couple of timer registers. The library did XOR its output against a second Yasmarang instance, which sounds like it might rescue the situation, right up until you notice that the second instance was seeded from hardcoded public constants. XOR two deterministic streams with known starting states and you get a third deterministic stream. The output looked random to a casual statistical test and to anybody eyeballing the words on screen, and it was fully reproducible by anyone who knew the recipe.

This is the kind of bug that gets caught by asserting on behavior rather than on the presence of a symbol. Nobody wrote a test that asked the device for a few million bytes and checked whether the hardware peripheral had actually been touched. The build succeeded, the words appeared, and five years went by.

Forty bits where 128 was promised

A 12 word BIP-39 seed is supposed to carry 128 bits of entropy, a number chosen specifically so that brute forcing it stays impossible for the foreseeable lifespan of the universe. Coldcard Mk2 and Mk3 devices running affected firmware produced seeds with roughly 40 bits of effective entropy. Mk4, Mk5, and Q devices did better at roughly 72 bits, which is still catastrophically short of the mark.

Forty bits is not a theoretical weakness that needs a nation state budget and a decade. Forty bits is a decent laptop and an afternoon. An attacker who can determine or sufficiently constrain the device UID, the timer state at the moment of generation, and the history of prior RNG calls can reproduce candidate output streams entirely offline. From there the work is mechanical. Derive the addresses for each candidate seed, compare them against the public blockchain, and keep the ones holding money. The blockchain is a free, permanently available, infinitely patient oracle that tells an attacker exactly which guesses were correct.

That is why the attack never needed to touch hardware, and it is why the 41 minute execution window is the least surprising detail in the entire story. All of the expensive computation happened well beforehand, offline, on the attacker's own machines. The sweep itself was just signing and broadcasting as fast as the network would take it.

Anyone who has been in this industry long enough has seen this movie. The Debian OpenSSL key generation disaster in 2008 came from a well intentioned edit that gutted the entropy pool. The Android SecureRandom flaw in 2013 drained Bitcoin wallets on the same basic principle. The failure mode never changes, because broken randomness does not throw errors, does not crash, does not slow anything down, and does not look wrong to a human reviewer. It just quietly hands the keys to whoever thinks to check.

Exposure depends on when the seed was born

The exposure rule here is unusual, and getting it wrong is going to cost people real money. Risk is determined by the firmware version that was running when the seed was created, not by the firmware version running today. Somebody who generated a seed on a Mk3 in 2022 and has diligently applied every update since is still fully exposed, because the weak seed is baked in permanently. Patching does not retroactively add entropy to a number that was already generated.

Coinkite's advisory covers Mk2 and Mk3 firmware versions 4.0.1 through 4.1.9 inclusive, which is where the roughly 40 bit exposure lives. It also covers seeds generated on Mk4 and Mk5 before standard version 5.6.0 or Edge version 6.6.0X, and on Q before standard version 1.5.0Q or Edge version 6.6.0QX.

There are two meaningful exceptions worth knowing. Seeds generated with at least 50 fair, independent, private dice rolls are considered safe from this flaw on its own, because the user supplied entropy carries the load that the broken RNG dropped. A strong BIP-39 passphrase layered on top of the seed also puts genuine work back in front of an attacker.

It is worth flagging how the disclosure unfolded, because it matters operationally. Coinkite's initial advisory named the Mk3, and only afterward did the company extend the warning to Mk4, Mk5, and Q owners. Anyone who read the first version, confirmed they were holding a Mk4, and closed the tab in relief needs to go back and read it again.

What to actually do about it

Update firmware first, then generate a new seed, then move funds, and the order genuinely matters. Generating a replacement seed on unpatched firmware reproduces the original problem exactly, and there is a certain grim comedy in the idea of responding to a broken random number generator by asking that same generator for another number.

Coinkite shipped emergency firmware across every affected model and release track on July 31, one day after the sweep. The fixed builds are 4.2.0 or later for Mk2 and Mk3, 5.6.0 or later for Mk4 and Mk5 on the standard track, 1.5.0Q or later for the Q, and 6.6.0X or 6.6.0QX for the corresponding Edge builds.

Once the device is patched, generate the replacement seed, verify the backup, and send a small test transaction before migrating anything meaningful. Only after that confirmation should the remaining balance move. The old seed should then be treated as permanently burned. It is not a spare, it is not a fallback, and it should never hold value again under any circumstances. For anyone who wants belt and suspenders, generating the replacement with dice removes the device RNG from the trust equation altogether.

Detection is a genuinely strange conversation for this incident, because there is nothing to detect on an endpoint. No anomalous outbound connection, no suspicious process, no beacon, no lateral movement. Galaxy Research, who mapped the sweep, noted that the transaction pattern "looks the same as if a coin owner chose to move coins," which is precisely the problem. The only available telemetry is watching known addresses for unexpected outbound movement, and that tells you what happened rather than what is about to. For organizations holding treasury in self custody, that monitoring should exist anyway, and it should page somebody at three in the morning.

The wider lesson deserves a moment of reflection. Every argument for hardware wallets ultimately rests on the quality of a single number, generated exactly once, usually within the first five minutes of ownership, by a code path that almost nobody audits after the fact. The device can be flawless in every other respect. Secure element, air gap, tamper evident packaging, open firmware, reproducible builds, all of it. If the seed was predictable, none of the rest ever mattered. Randomness is the foundation the entire structure sits on, and it is also the one property that is effectively impossible to verify by looking at the output.

Any client holding cryptocurrency in self custody should be treated as having an asset class with no chargebacks, no insurance, no reversal window, and no help desk. Coldcard owners need to check their firmware history today rather than at the next quarterly review, because the attacker who did this already has the candidate list and is presumably still working through it.