A Coldcard Bug Made Bitcoin Seeds Guessable. $38 Million Vanished in 25 Minutes
• July 31, 2026 10:55 am • CommentsA hardware wallet is supposed to keep a Bitcoin key beyond an online attacker’s reach.
Hundreds of Coldcard owners just learned that isolation cannot protect a key that was not random enough when it was created.
An attacker swept roughly 594 Bitcoin, worth about $38 million, from approximately 500 wallets in a 25-minute burst early Friday.
The theft did not require cracking Bitcoin. Researchers traced it to a firmware integration error that made certain Coldcard devices generate wallet secrets from a dangerously restricted set of possibilities.
The onchain sweep moved 562 BTC into one address after draining the individual wallets.
🚨 NEW: Over 594 BTC worth $38 million was stolen from Bitcoin hardware wallet Coldcard users.
The attacker then moved around the BTC and consolidated 562 BTC into this address below.
Users are urged to review the company's official security guidance as soon as possible. ‼ pic.twitter.com/exD2Wax7CY
— Bitcoin Magazine (@BitcoinMagazine) July 31, 2026
The affected wallets were all single-signature addresses holding more than 0.15 BTC, according to the initial transaction analysis.
Many had been dormant for years. That gave an attacker a quiet pool of old funds whose owners may have believed offline storage had removed the main avenue of attack.
The failure began in March 2021, when a firmware change moved seed generation onto a different random-number path.
Coldcard’s intended hardware random-number generator was still present. The wallet-generation code reached a deterministic software fallback instead.
That distinction is devastating.
A properly generated Bitcoin seed comes from a space so large that guessing it is effectively impossible. A deterministic fallback can produce numbers that look random while still coming from inputs an attacker can reconstruct or narrow down.
Block’s Bitcoin Engineering and Security teams traced the error to the way Coldcard’s firmware integrated MicroPython with its libNgU cryptographic library. A build flag disabled MicroPython’s hardware-RNG implementation because Coldcard had its own wrapper, but libNgU checked only whether the flag existed—not whether it was set to zero.
The software therefore bound to a fallback generator seeded from the device identifier and clock registers. Those values are device and timing data, not a cryptographic secret, and the resulting stream can be reproduced when enough of that state is known.
Block says Mk2 and Mk3 devices running the affected version-four firmware had no cryptographic entropy added through that path. Later Mk4, Q and Mk5 devices mixed in secure-element data, but only a limited portion survived into the reseed operation, leaving far less protection than the intended 128-bit target.
The vulnerable seed remains vulnerable after it is imported into a newer wallet. Replacing the device or updating firmware does not change the secret that controls the old addresses.
Coinkite initially said newer models appeared unaffected. Its updated advisory now covers seeds generated on older firmware across Mk3, Mk4, Mk5 and Q devices.
The company released emergency firmware and published model-specific migration instructions Friday morning.
🚨 COLDCARD SECURITY UPDATE [Jul 31, 9:40 EDT]
Mk3 4.2.0 is now available.
Affected seeds without ≥50 fair, independent, private dice rolls:
👉 Mk3 4.0.1–4.1.9
👉 Mk4/Mk5 <5.6.0
👉 Q <1.5.0QUpdate first. Generate a new seed. Migrate carefully.https://t.co/HshUxevCl3 https://t.co/aC2zdazILQ
— COLDCARD (@COLDCARDwallet) July 31, 2026
The fixed versions are 4.2.0 or later for Mk3, 5.6.0 or later for Mk4 and Mk5, and 1.5.0Q or later for Q.
Those updates correct the generation of new seeds. They do not repair a seed that an affected firmware version already created.
Coinkite’s security advisory tells affected users to install fixed firmware before creating a replacement wallet, verify the new backup and receive address, send a small test transaction and only then move the remaining balance. The company cautions users to proceed calmly because a rushed migration can create its own immediate risk.
The advisory covers Mk3 seeds generated on firmware 4.0.1 through 4.1.9, Mk4 and Mk5 seeds created before version 5.6.0, and Q seeds created before version 1.5.0Q. TAPSIGNER, OPENDIME and SATSCARD use different codebases and are not affected.
There is one important exception. At least 50 fair, independent and private dice rolls during original seed creation contributed enough separate entropy that Coinkite does not consider the resulting seed at risk from this flaw alone.
A strong, unique BIP-39 passphrase also creates an additional barrier, but a short or reused phrase should not be assumed safe. The wallet PIN is not the same thing as a BIP-39 passphrase.
Coinkite’s technical explanation estimates that affected Mk3 seeds had roughly 40 bits of effective search space under its current assumptions. The company estimates approximately 72 bits for affected Mk4, Q and Mk5 seeds because those models mixed in additional secure-element entropy, though that still fell well short of the intended 128-bit security target.
The company says the error survived because the intended hardware-randomness code existed in the firmware binary and the incorrect fallback exposed the same function signature. Prior review confirmed that the proper code was present but did not follow the complete call path used during wallet creation.
Coinkite also said one of the best available AI models had reviewed its code weeks earlier without finding the bug. Open source made independent investigation possible, but public code did not automatically make the integration safe.
Hardware wallets still remove many risks created by keeping private keys on an internet-connected phone or computer.
They do not eliminate firmware risk, implementation mistakes or the consequences of generating a weak secret at the beginning.
The Bitcoin network did exactly what its rules require. It accepted valid signatures from keys that an attacker was able to recover.
That is why this incident is so severe: the coins were protected by hardware, but the weakness existed before the first transaction was ever signed.
Join the conversation!
We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.
