The Coldcard Drain Is Not Over. Here Is What We Can Verify.

The drain did not stop in July

On July 30, 2026, attackers started emptying Coldcard hardware wallets. No one was phished. No device was touched. Wallets in safes and safety deposit boxes were drained while their owners slept.

The story did not end there. September brought three real developments: hardened firmware releases, a white-hat recovery trust, and the wave-three attacker starting to launder the loot. But be careful. Some “new Coldcard attack” headlines circulating in October are recycled write-ups of an August alert, not fresh attacks. This piece separates what we can verify from what we cannot, explains the flaw in plain terms, and tells Coldcard owners exactly what to do.

A note on sourcing. Coinkite is the vendor and its statements are claims, not proof. Everything below is verified against independent researchers: Block’s Bitcoin engineering team, Galaxy Research, TRM Labs, and security reporters who interviewed them.

What actually changed in September 2026

1. Coinkite shipped hardening firmware

Firmware 5.6.1 (Mk4 and Mk5) and 1.5.1Q (Coldcard Q) made user-supplied entropy mandatory for every newly generated seed. At least 65 keypresses with unpredictable timing, 50 die rolls, or 128 coin flips. That input is folded into randomness from the device’s secure elements and hardware RNG, so the seed stays unpredictable even if one source fails. The release also re-verifies transactions right before signing, adds boot-time hardware RNG checks, restricts USB downloads behind an encrypted session, and blocks risky Bitcoin signature hash modes by default. (CryptoNexa, reporting Coinkite’s release notes)

A second build followed fast. Firmware 5.6.2 and 1.5.2Q restore visibility into the device-generated entropy used at seed creation and add a standalone tool to independently verify dice-roll or coin-flip mixing. Those are the current recommended releases. Older hardware tops out at 4.2.0 (Mk2/Mk3) and 3.0.6 (Mk1). (Cointelegraph)

2. White hats swept 52.37 BTC into a recovery trust

Not every outflow was theft. On September 22, white-hat operators moved 52.37 BTC from Wave 2 exploit funds into an address linked to a new Crypto Recovery Trust, with an on-chain note pointing to cryptorecoverytrust.com. That is about 2.8 percent of the tracked exploit funds. Galaxy’s Alex Thorn says roughly 40 percent of Wave 2 activity now looks like protective sweeps, not theft. Victims can check their addresses on the trust’s site and claim without handing over private keys. (CoinDesk, September 22)

3. The Wave 3 attacker started cashing out

On September 2, the attacker behind the third wave routed about 20.5 BTC from its largest vault through THORChain, with proceeds landing on Ethereum. On September 5 and 6, another 76.6 BTC went through CoinJoin transactions. In total, 97.09 BTC, roughly 45 percent of the wave-three haul, has moved. The attacker built one 2-of-2 multisig vault per victim and has been emptying them largest first. Galaxy has now engaged directly with more than 190 victims and identified a new 58-address vault it believes belongs to more Coldcard victims. (CoinDesk, September 7)

Verified vs unverified: the honest breakdown

Verified

• The root cause. A March 2021 firmware integration error (version 4.0.1) routed Coldcard seed generation to a deterministic MicroPython fallback random generator instead of the device’s hardware random-number generator. The TRNG existed and worked. The seed path simply did not call it. (Block’s engineering report, July 30, via Infosecurity Magazine)
• The entropy loss. Seeds generated on affected Mk2/Mk3 firmware carry roughly 40 bits of effective entropy. Mk4, Mk5, and Q seeds carry about 72 bits. The design target was 128 bits. TRM Labs confirmed the 128-to-40-bit collapse for the worst-affected path. (CryptoNexa, citing TRM Labs and Coinkite estimates)
• Only single-sig wallets were drained. No multisig address appears among the victims in the first three waves. One weak key is fatal for single-sig. Multisig requires several independent keys, so one vendor’s bug is not enough. (The Cryptonomist, citing Galaxy)
• At least 15 separate attackers. Galaxy’s tally comes from victim reports, not speculation. One victim’s report of less than 1 BTC led researchers to a 12 BTC sweep across 126 addresses. (Cointelegraph)
• Confirmed scale. Galaxy’s August 14 tally: 1,778 BTC across the confirmed waves, the third-largest crypto exploit of 2026 per DefiLlama. A separate pattern-matched cluster would push the total near 1,816 BTC, but that cluster is not victim-confirmed. (CryptoNexa)
• Updating firmware does not fix an old seed. A patch stops new weak seeds from being created. It cannot change the seed that was already generated. Affected seeds must be replaced, not patched over. (bitcoin.tax)
• The white-hat recovery is real. 52.37 BTC consolidated to the Crypto Recovery Trust address in block 967,948, claimable at cryptorecoverytrust.com. (CoinDesk, September 22)

Claimed but unverified

• Whether one actor ran every wave. Galaxy explicitly says it cannot determine this from blockchain data. Multiple operators racing each other is just as plausible.
• The exact totals. Estimates run from 1,778 to 1,816 BTC depending on which clusters you include. They assume the victim groups do not overlap. Treat every headline total as a range, not a fact.
• The “fourth wave.” Thorn flagged a 709-address, 448.73 BTC pattern cluster on August 3. It rests on transaction pattern matching. No victim has confirmed it, and Galaxy omits it from its high-confidence headline. It is a real signal, not a confirmed loss total. (Cointelegraph)
• The October “new wave” stories. Pieces dated October 1, 2026 describing the 448 BTC sweep are recycled write-ups of the August 3 alert. Same blocks (960,778 to 960,792), same numbers. There is no verified new attack wave in October.
• The May 2025 warning. Bitcoin developer James O’Beirne says he raised the randomness issue with Coinkite in May 2025 and was told the problem would likely have surfaced already. That is his account. Coinkite has not confirmed or denied it. (Phemex)

False or outdated

• “The attacker had physical access to the devices.” False. Seeds were reconstructed offline from weak entropy. No device was touched.
• “Update your firmware and you are safe.” False for any seed generated on affected firmware. The seed itself is the vulnerability now.
• “Cold wallets are automatically the gold standard.” Outdated as an assumption. Cold storage protected the device, but the keys it generated were searchable. The weakest link was never the safe. It was the randomness.

The flaw in plain terms

A seed phrase needs true randomness. Coldcard had a proper hardware random-number generator built in. In March 2021, a firmware change accidentally pointed the seed-generation code at a different generator, a predictable software one baked into the code base. The good RNG kept running. Reviews could see it. Nothing checked that the seed path was actually calling it.

With only 40 to 72 bits of effective entropy, an attacker can enumerate candidate seeds offline, derive the addresses, and check them against the public blockchain. No mempool watching needed. Victims were selected by seed age, not by behavior. If you added your own entropy at setup, dice rolls, coin flips, or a passphrase, the weak device output was not the only input, so your seed would not sit in the same searchable space. And none of the drained wallets were multisig, which is why spreading key generation across vendors and devices is the single strongest lesson of this incident. See our multisig guide and the Assistant Multisig.

Who was hit, and who was not

Hit: single-signature Coldcard wallets whose seeds were generated on affected firmware. Affected ranges: Mk2 and Mk3 on 4.0.1 to 4.1.9, Mk4 and Mk5 before 5.6.0, Coldcard Q before 1.5.0Q, Edge models before 6.6.0X and 6.6.0QX. (bitcoin.tax) Many victims had coins sitting untouched for years, some dating back to 2021.

Not hit: multisig wallets, users who added their own entropy or a passphrase at seed creation, seeds generated on fixed firmware (5.6.0+, 4.2.0 for Mk2/Mk3, 3.0.6 for Mk1, and the September 5.6.2/1.5.2Q releases). The hardware wallet compatibility checker can help you compare devices when rebuilding your setup.

If you are choosing a new signing device, our best Bitcoin wallet guide walks through the tradeoffs, and our piece on why seed words alone are not enough covers the entropy side of this story. For deep cold storage thinking, see the case for Bitcoin Core cold storage.

What to do if you own a Coldcard

1. Check when your seed was born, not which firmware you run now. The firmware version on the device today tells you nothing about the seed’s birth conditions. If the seed was generated on any affected firmware above, treat it as compromised.
2. Update, then generate a brand-new seed. Move to the latest firmware (5.6.2 for Mk4/Mk5, 1.5.2Q for the Q, 4.2.0 for Mk2/Mk3, 3.0.6 for Mk1), then create a fresh seed. Use the new mandatory entropy step: dice rolls or coin flips.
3. Move your coins to the new wallet. Do not restore the old seed words anywhere and keep using them. The old seed is the vulnerability.
4. Verify your exposure. Coinspect’s free Unlukey tool at illbloom.org checks whether an address falls in the weak-seed dataset. If white hats swept your coins first, check cryptorecoverytrust.com. (CryptoNexa)
5. Consider multisig for serious holdings. No multisig wallet was drained in any wave. Two or three keys across different vendors means one vendor’s bug cannot empty you. The Assistant Multisig builds your exact setup in minutes.

Updating firmware protects future seeds. Only a fresh seed protects your coins.

The real lesson

Five years. That is how long a deterministic generator sat in the seed path of the most trusted Bitcoin-only hardware wallet, while the proper RNG ran right next to it, unused where it mattered. Code reviews saw the TRNG. Nobody verified the seed path called it. Kraken’s security chief put it bluntly: the payments industry does not ship PIN pads without independent lab testing, and governments do not accept crypto modules without entropy validation. Hardware wallets have no equivalent requirement. (Cointelegraph)

The fix is structural, not tribal. Do not trust a brand. Do not trust a single device. Generate seeds with your own entropy, verify the entropy path, and hold serious coins in multisig so no single point of failure can do this to you again.