What happened (and how it got weird)

On July 30 an attacker emptied 1,196 Bitcoin addresses in just 41 minutes — about 1,082.65 BTC, roughly $70 million at the time. Researchers traced the activity back to a weakness in the Coldcard family of Bitcoin-only hardware wallets: a quirk in how some firmware builds created wallet seeds.

Long story short: a March 2021 firmware change accidentally let seed creation fall back to a predictable software routine instead of using the chip’s real hardware randomness. That software fallback seeded itself from the chip’s unique ID and timer values and then failed to collect any fresh entropy afterward. If an attacker can narrow down the device UID, boot timing and prior RNG usage, they can reproduce candidate outputs offline and check whether any match addresses on the blockchain.

Firmware fixes were pushed out quickly the day after the theft, but flashing the updated firmware does not magically repair seeds that were already made with the flawed generator. In plain English: patched devices stop producing new weak seeds, but any vulnerable seed already created stays vulnerable until you replace it.

The affected models and the technical nitty-gritty

The exposure depends entirely on which firmware was running when the seed was originally generated, not what the device runs now. In short:

  • Mk2 / Mk3: Certain builds from the vulnerable 4.0.x and 4.1.x series are implicated.
  • Mk4 / Mk5: Anything before 5.6.0.
  • Q: Anything before 1.5.0Q.
  • Edge builds: Early edge releases for Mk4/Mk5 and Q before specific 6.6.x edge releases are affected.

Security researchers estimated the effective randomness on some models could be far below recommended levels (e.g., much less than a full 128-bit BIP‑39 seed), turning what should be astronomically hard brute-force problems into something far more tractable for a targeted attacker, depending on what extra device info they can guess or observe. The bug stems from MicroPython falling back to a deterministic generator (think of it as a cheap imitation of randomness).

Importantly, there’s been no public, verified match of a reconstructed seed to a drained address so far, and the identity of the thief remains unknown. The transaction pattern researchers mapped out did look like a coordinated sweep, but that pattern alone can’t prove theft versus someone legitimately consolidating coins.

Also worth noting: this follows earlier reports this summer about weak-PRNG issues in other wallet codebases, so the ecosystem is on higher alert for entropy-related mistakes.

Your quick action plan (do this now, not later)

  • Check when your seed was created. If it was created on a device at an affected firmware version, treat it as compromised.
  • Update your wallet to the patched firmware immediately, even though that alone won’t fix existing seeds.
  • Generate a brand-new seed on the patched firmware and move your funds to it. Restoring the old seed to updated firmware or another wallet preserves the old weakness—don’t do that.
  • If you used manual entropy (like dice) and can prove you used at least 50 fair, private rolls, you’re probably fine from this bug alone. If you’re unsure, re-seed anyway.
  • Use a strong, unique BIP‑39 passphrase (it creates an additional protected wallet) but don’t treat it as a full substitute for reseeding—the vendor still recommends migrating.
  • Multisig reduces risk only if not all signers use affected devices. Consider adding signers on different hardware or software stacks.
  • If you’re confused or anxious, contact the vendor support, and move funds to a clearly safe seed created after firmware updates.

Final laughably bleak note: randomness is boring until it isn’t. Treat your wallet’s seed like a secret recipe — if the chef used expired spices, throw the dish away and cook a new one.