The Coldcard Exploit Is Still Running — and the Migration Is Where Victims Fail

We published our client advisory on this exploit in August. This is not that article. The question then was what happened and are you affected. The question now, nearly three months on, is why the exploit is still running — and why people who understood the bug are still losing funds during the fix.

The numbers first. Galaxy Research's running tally stands near 1,816 BTC, roughly $116 million, drained from more than 5,200 addresses across four sweep waves since July 30, 2026. TRM Labs calls the figure preliminary. On-chain analysts estimate around 90% of the stolen bitcoin is still sitting at attacker-controlled addresses, unmoved. At least a dozen distinct attackers are believed to be working the same bug. That unmoved 90% is the part that matters to you: it means the attackers are not in a hurry. Enumeration is cheap, offline, and doesn't stop when the firmware patch ships.

Why a patch can't stop this

The flaw means your seed has roughly 40 bits of real entropy (Mk2/Mk3) or at best 72 bits (Mk4/Mk5/Q) instead of 128. An attacker can enumerate candidate seeds offline, derive addresses, and check them against the blockchain. Your xpub — or a single address — is the validation oracle. No exploit code needs to run on your device, so no firmware update touches the attack.

Coinkite shipped fixed firmware on August 1 for every affected model. That fix changes how new seeds are generated. It does nothing for seeds created on firmware 4.0.1 through 4.1.9 (Mk2/Mk3), before 5.6.0 standard or 6.6.0X Edge (Mk4/Mk5), or before 1.5.0Q standard or 6.6.0QX Edge (Q). A fixed device holding an old seed is a corrected factory that already produced a broken part. The seed must be replaced. Every week of delay, the enumeration keeps running.

Failure mode 1: the migration transaction itself

The most brutal irony of this incident: the act of escaping can hand the attacker your funds. In a SegWit wallet where all the keys come from affected Coldcards, the first spend reveals the full wallet descriptor. From that moment an attacker who knows the keys can derive every address, watch the mempool, and — when you broadcast the migration transaction — replace it with a higher-fee version paying themselves instead. RBF makes this trivial.

The rule is absolute: do not broadcast migration transactions directly from an affected single-sig SegWit wallet or an all-Coldcard multisig wallet. Use an out-of-band submission service such as Mara Slipstream, which publishes the transaction without exposing it to replacement, or migrate through a Taproot wallet, where the script details stay hidden until you spend. If you've already revealed the descriptor, every future address in that wallet is visible to the attacker — the migration is a one-shot operation, not something you can leave half-finished.

Failure mode 2: misreading the multisig math

Multisig owners are the most common victims of false confidence. The question is not do I use Coldcard. The question is: can any single spending path be satisfied using only affected keys?

A 2-of-3 quorum with two Coldcard keys is compromised outright, because the affected keys meet the threshold on their own. A 2-of-3 with only one Coldcard key is not immediately sweepable, but it is exposed — especially in SegWit, where the descriptor comes on-chain at first spend and hands the attacker the full policy. A quorum of freshly seeded or non-Coldcard devices is safe on this vector.

Wizardsardine's recommendation is now the industry standard: multi-vendor multisig where no single brand can meet any path's threshold. One vendor's RNG failure should never be capable of draining your funds alone. And note that if you reseed your Coldcards for that multisig, the new seeds must be generated on patched firmware — or better, via the dice-only import path with 99+ rolls, which never touches the device generator at all.

Failure mode 3: BIP-85 contamination

Many people will migrate their bitcoin and consider the job done. If you used BIP-85 derived keys, it isn't. Everything derived from the affected seed inherits the weakness: Nostr keys, Lightning node seeds, SSH keys, duress wallets behind trick PINs, and passwords generated in Secure Notes. A "successful" fund migration that leaves a Lightning node seed or a duress wallet derived from the old seed is an incomplete migration.

Worse, several Coldcard features drew directly from the broken PRNG, bypassing the seed entirely. Paper wallets created on-device, clone-to-another-device key exchanges, Seed XOR shares, HSM mode secrets, and the password generator are compromised regardless of how your main seed was created. Wizardsardine has documented at least nine such features; Coinkite has not published a complete list. Assume anything that touched the device's randomness is tainted.

Failure mode 4: trusting the fix too far

The firmware fix is real and independently verified — researchers confirmed hardware TRNG reads on real devices and reproducible builds matching the signed release. But three limitations bite people:

Track confusion is the first: standard and Edge are separate release tracks, and installing the standard fix on an Edge device remediates nothing. Passphrase false comfort is the second: a BIP-39 passphrase adds a barrier but does not repair the seed, and with only 2,048 PBKDF2 iterations a known seed plus your passphrase is crackable in hours — Wizardsardine's verdict is to consider your passphrase not secure, and Coinkite tells passphrase users to migrate anyway. Rushed migration is the third: Coinkite itself warns that a rushed migration creates more immediate risk than the bug, so record and verify the new backup before you touch the old wallet.

The playbook, in order

Confirm exposure: model and firmware at Advanced/Tools → Danger Zone → Firmware Version. If the seed was generated on affected firmware, treat it as compromised — no matter where it lives now. Update firmware on the correct track (Mk2/Mk3 → 4.2.0+; Mk4/Mk5 → 5.6.0+ standard or 6.6.0X+ Edge; Q → 1.5.0Q+ or 6.6.0QX+ Edge), verifying the SHA-256 checksum from coldcard.com only. Generate a new seed on patched firmware — or 99+ dice rolls on the dice-only path for zero trust in the device generator. Migrate over an out-of-band submission service if the old wallet is SegWit with all-Coldcard keys; otherwise test-transaction first, then the balance. Rotate every BIP-85 derived secret: Nostr, Lightning, SSH, duress wallets, generated passwords. Destroy the paper wallets and clone files made on the old device. Re-architect to multi-vendor multisig so no single brand can ever meet a threshold alone.

The attackers ran this bug's numbers for years before July 30, and they have not stopped since. The stolen coins sitting unmoved are not evidence of patience running out — they are evidence of patience. The people who fail will not fail at understanding the bug. They will fail at the boring middle: a broadcast they shouldn't have made, a threshold they miscounted, a derived key they forgot.

We covered what happened and which devices are affected in our client advisory and our scope analysis. If you want a second pair of eyes on your migration plan, that is exactly what we do.

Sources: Coinkite Security Advisory; TRM Labs on-chain analysis; Block Engineering root-cause analysis; Wizardsardine technical analysis; Coldcard Security Status. This article is for education only and is not trading or legal advice.