What happened (quick and dramatic)

On July 30 an attacker swept hundreds of Bitcoin addresses in a blur — about 41 minutes — taking roughly 1,082.65 BTC (around $70.2 million at the time). Follow-up chain sleuthing later increased the observed total to about 1,367.05 BTC across thousands of addresses (roughly $88.6 million). This wasn’t a mysterious new exploit from the ether, it traced back to a subtle firmware bug in certain Coldcard devices that leaked deterministic randomness during seed generation.

Here’s the short version: a 2021 firmware integration mistake caused some Coldcard models to fall back to a software pseudorandom generator rather than the chip’s hardware random source. That fallback used values like the device unique ID and timers to initialize itself and then didn’t collect fresh entropy, meaning an attacker who could guess or narrow those inputs could reproduce candidate seeds offline and check whether they control any addresses on the public blockchain.

Who was exposed, what to do, and other spicy details

Important mechanics and context:

  • Coinkite pushed emergency firmware fixes on July 31, but updating a device does not magically heal an already-created seed. If your seed was generated while the vulnerable firmware was running, the seed itself may still be at risk.
  • Attackers don’t need physical access if they can constrain things like the device UID, boot timing, and prior RNG calls — those reduce the guessing space for the flawed PRNG.
  • The real weakness here is weak entropy at seed creation: some models were effectively producing far fewer bits of randomness than a healthy BIP-39 seed expects.

Devices and builds flagged as potentially vulnerable (exposure depends on the firmware that was running when the seed was created):

  • Mk2 and Mk3: certain 4.0.x–4.1.x builds (Mk3 fixed in 4.2.0; Mk2 is placed on the same vulnerable path by analysis).
  • Mk4 and Mk5: any build before 5.6.0.
  • Q: any build before 1.5.0Q.
  • Edge test builds: older edge builds on Mk4/Mk5 and Q are also flagged if below the listed edge versions.

What you should do (stop reading and act, or at least pause dramatically):

  • If your seed was created on an affected build, generate a brand-new seed on patched firmware and move your coins immediately to addresses created by that new seed.
  • Do not restore the old seed onto patched firmware or another wallet — that just carries the weakness forward.
  • If you truly created your seed with at least 50 private, fair dice rolls, you’re likely safe from this bug alone, but if you have any doubt, migrate the funds.
  • A strong, unique BIP-39 passphrase adds a useful layer, but the company still recommends replacing the seed to be safe.
  • Multisig only helps if the other cosigners are not all running affected devices.
  • Some other devices that use different codebases are not affected; check your product docs rather than assuming everything with a similar name is vulnerable.

Other notes and the drama around attribution:

  • No public conclusive ID of the attacker yet. Chain analysis teams mapped sweeping patterns and shared suspect addresses with investigators and compliance groups.
  • On-chain pattern matching found groups of sweeps that might share an operator, but on-chain similarity doesn’t equal proof — a legitimate owner moving coins can look the same as a thief sweeping them.
  • This episode echoes other recent incidents where weak PRNGs in wallet code led to millions of dollars lost across chains; randomness failures are boring to fix and explosive when exploited.

Final, practical takeaway: update firmware, treat any seed created on the vulnerable builds as suspect, and move funds to seeds generated only after the fix. And maybe keep a box of dice handy — if you actually used private dice to make your seed, you were on the smart side of chaos.