The keys stayed offline, but the secret was guessable
The July 2026 Coldcard thefts did not involve remote access to the hardware wallets. Attackers worked without the devices, their PINs, or malware on the owners' computers. The vulnerable wallets had been created with seeds drawn from a much smaller set of possibilities than their owners were promised. Attackers could search that set offline, derive the corresponding Bitcoin addresses, compare them with the public blockchain, and spend any matching coins.
Beginning on July 30, attackers swept funds from thousands of addresses. By August 14, Galaxy Research had confirmed with high confidence that 1,778.84 BTC, worth about $112.7 million at the time, had been stolen from more than 8,600 addresses. Galaxy had spoken directly with 190 victims and identified several attack patterns. It also found evidence that more than one attacker was active.
Those 8,600 addresses are not 8,600 stolen devices. One deterministic wallet can control many addresses. That distinction matters because the event exposed a failure in seed creation, not a breach of the device's offline storage after setup.
Galaxy found no confirmed attacker activity after August 6, but it did not declare the remaining wallets safe. Its plausible explanations included successful user migration and the possibility that attackers had already taken much of the accessible balance. Any funds left on an affected seed remain exposed.
A build error weakened five years of seeds
Coldcard intended to generate wallet seeds from a hardware true random number generator. During a March 2021 migration to a supporting library, the seed-generation path began resolving to MicroPython's general-purpose Yasmarang pseudorandom generator instead.
The failure sat at a build and linking boundary. A configuration macro set the hardware RNG option to zero. A library guard used #ifndef, which checked whether that macro existed rather than whether it was enabled. The build succeeded, but the global rng_get() symbol used by seed generation resolved to the deterministic software implementation. Coinkite's hardware RNG code was present in the binary, yet the relevant call path did not reach it.
The fallback was initialized from device identity and timing state. Those values can vary, but variation is not the same as cryptographic unpredictability. Hashing the resulting bytes could make them look uniformly random. It could not increase the number of possible seeds.
Coinkite estimated an effective search space of about 40 bits for affected Mk3 seeds under its attack assumptions. It said later devices mixed in secure-element entropy and estimated about 72 bits. A coordinated Block engineering analysis reached a harsher result: no cryptographic entropy entered the Mk2 and Mk3 v4 path, while only one 32-bit state word distinguished later-device streams once the fallback state and call history were fixed.
The two estimates rest on different assumptions about what an attacker knows. They should not be merged into one number. Attackers still recovered real wallets at scale.
The firmware was open source and reproducible builds were available, yet the bug remained. Existing review had checked that the intended RNG implementation was present, but not which implementation the shipped seed-generation path actually called. For security-critical randomness, source review must be paired with tests of the final binary, symbol resolution, call reachability, and fail-closed behavior.
The risk depends on the seed's origin
The relevant version is the firmware that generated the seed, not the firmware installed today. Moving the same seed to another hardware wallet also leaves it weak. Conversely, a seed generated by a sound external process and later imported into an affected Coldcard does not inherit this particular generation defect, although its security still depends on that original process.
The Coldcard security matrix, checked on September 23, lists these minimum fixed releases. They identify the original seed-generation fix, not the latest recommended firmware:
| Model and track | Seed generated on affected firmware | Minimum fixed release |
|---|---|---|
| Mk2 or Mk3 | 4.0.1 through 4.1.9 | 4.2.0 or later |
| Mk4 or Mk5 standard | Before 5.6.0 | 5.6.0 or later |
| Mk4 or Mk5 Edge | Before 6.6.0X | 6.6.0X or later |
| Q standard | Before 1.5.0Q | 1.5.0Q or later |
| Q Edge | Before 6.6.0QX | 6.6.0QX or later |
The vendor's September 4 update recommends standard release 5.6.2 for Mk4 and Mk5, and 1.5.2Q for Q. Standard and Edge are separate tracks, so their version numbers cannot be compared directly. For Mk2 and Mk3, 4.2.0 is the final release; it can generate a replacement seed, although Coinkite recommends current hardware for long-term custody.
The vendor's dice exception requires at least 50 fair, independent rolls entered through Add Dice Rolls, a private and unrecorded sequence, and use of the final seed words displayed after mixing. Fifty qualifying six-sided-die rolls supply about 129 bits of independent entropy. Merely rolling dice, or backing up the words shown before adding them, does not satisfy the exception. If any condition is uncertain, follow the migration guidance.
A strong, unique BIP-39 passphrase can slow or prevent use of a recovered mnemonic, but it does not repair the underlying seed. The BIP-39 specification also creates a subtle recovery risk: every passphrase, including a typo, produces a valid but different wallet. Owners who cannot prove that the passphrase is strong, exact, separately backed up, and recoverable should not use it as a reason to delay migration.
If the device, generation version, or dice history is unknown, the safer assumption is that the seed needs replacement.
Migration is the fix, not a firmware update
Updating firmware changes future seed generation. It cannot add entropy to a seed that already exists. Only a completely new seed followed by an on-chain transfer removes the exposure.
The vendor's migration procedure is careful because hurried recovery work can create a second loss. The guide recommends a second device so owners do not have to alternate between old and new seeds. Before changing either wallet, verify the old backup and fingerprint; never erase the only working copy. The following is a summary, and the linked guide provides the model-specific and one-device instructions:
- Install the appropriate current firmware from the official source after checking its SHA-256 hash and signed release information.
- Generate a completely new seed using the verified firmware's documented workflow, including any user entropy required by that release. Do not clone, import, or restore the old seed.
- Record the new seed backup offline and verify it on dedicated hardware using the vendor's documented procedure. Keep seed words off computers and websites. Record the wallet fingerprint, then power-cycle the device, confirm that fingerprint, and verify a receiving address on its screen.
- Send a small test transaction from the affected wallet. Confirm that it arrived in the expected new wallet before moving the remaining balance.
- Reconcile every funded account and retain the old backup until the full migration is verified. Stop if a fingerprint or address does not match.
Migration must cover more than the base wallet. Every funded passphrase wallet must move. If the affected seed is a BIP-85 parent, every funded child needs attention. In multisig, replace the affected cosigner through a new verified policy and transfer to that policy. Reusing the same passphrase or child index with a new seed produces a different wallet.
During an urgent migration, adding an untested passphrase or building a first multisig setup can increase operational risk. Move first through a process you can verify. No legitimate support agent needs seed words, a passphrase, dice rolls, an XPRV, or a private-key QR code.
Hardware wallets fail in more than one way
Coldcard failed during seed generation. Other hardware-wallet losses can begin later, after a sound seed already exists. Each failure point needs a different control.
Weak seed generation happens before cold storage can help. Defenses include fixed firmware, verified release files, documented user-supplied entropy, independent testing, and, for holdings that justify the complexity, multisig seeds generated on genuinely separate devices and implementations.
Seed-backup theft bypasses the device entirely. A photo, cloud copy, email, ordinary computer file, or seed entered into a website can give an attacker everything needed to spend. Backups should remain offline, and the seed, device, and any passphrase should not be stored together.
Host malware can change a recipient address or transaction while leaving the private key inside the hardware wallet. The defense is to verify the amount, destination, fee, and policy on the trusted hardware display before signing. Air-gapped transfer does not help if the user approves a malicious transaction without reading it.
Physical theft gives an attacker time with the device. A strong PIN and a separately stored passphrase can buy protection, but they are not a reason to wait indefinitely. If a signer disappears or shows evidence of tampering, create a fresh wallet through a known process and move the funds. If the seed backup is missing too, treat the event as an immediate key compromise.
Supply-chain tampering begins before setup. Buy through a channel you can authenticate, inspect the device and packaging, install verified current firmware, and reject any device that arrives with a prewritten seed or asks you to use recovery words supplied by someone else. A sealed bag can reveal interference, but it cannot prove that the device is genuine or the firmware clean.
How to set up and test a safer wallet
Before depositing an amount you could not easily replace, document where the seed came from, which firmware generated it, and the wallet fingerprint. The record should identify versions and public wallet data, never the seed words or passphrase.
Generate recovery words on the hardware device or through another procedure you have independently verified. Never improvise a mnemonic from favorite words, use an online generator, or assume that a valid BIP-39 checksum proves randomness. On Mk4/Mk5 5.6.2 and Q 1.5.2Q, standard new-seed generation requires one user input alongside device entropy: at least 65 key presses with unpredictable timing, 50 physical die rolls, or 128 physical coin flips. Dice Rolls Only is a separate advanced workflow; do not apply these mixed-input thresholds to it.
Write or stamp the seed offline. Store duplicate backups in locations that do not fail together. Coinkite recommends a strong, unique BIP-39 passphrase for a balance whose loss would materially harm its owner. Back it up exactly and separately, record the passphrase wallet's fingerprint, and test recovery before funding it. For an urgent migration, the vendor says not to delay the move to add an untested layer.
Test recovery before the wallet holds a painful amount. A safe rehearsal confirms the fingerprint and derived receive address on dedicated hardware. It does not require typing the real seed into a laptop or browser. Send a small amount, recover the wallet, and confirm that the same address set returns.
For routine spending, verify every destination on the hardware display. Maintain a watch-only view for balance and unexpected movement, preferably without handing an extended public key to an unknown service. A watch-only wallet cannot spend, but an exposed XPUB can reveal transaction history and future addresses.
Large holdings may justify 2-of-3 multisig across different vendors, with each seed generated independently and backups distributed across separate locations. This can survive one weak seed, one failed device, or one lost backup. It also creates policy-file, inheritance, and recovery obligations. A multisig design that nobody can restore is not safer than a well-run single-signature wallet.
What Coldcard changes for self-custody
Hardware wallets still reduce important risks, especially exposure of private keys to networked computers. Coldcard's failure occurred earlier in the process. Some devices created weak secrets before offline signing began.
Users cannot inspect a 24-word phrase and tell whether it has 40 bits of effective entropy or 256. The words and checksum can look perfectly normal in both cases. That makes seed provenance part of the backup: model, release track, firmware at creation, entropy method, fingerprint, and recovery test all matter.
Vendors need stronger evidence for seed-generation claims than an open repository or a random-looking output sample. The shipped binary should prove which entropy source is reached, stop when that source fails, and test the complete path across library and linker boundaries. Independent review should reproduce those results on real devices.
For owners, adding passphrases, dice, separate signers, and multisig can reduce concentrated technical risk. Every layer also creates more recovery work and another place to make a mistake. The appropriate setup depends on the amount at stake and the owner's ability to rehearse it. If a life-changing balance depends on one device-generated seed and nobody can verify how that seed was created, the wallet needs a new recovery plan.
Sources
The loss figure uses Galaxy Research's high-confidence set and excludes medium-confidence or unconfirmed clusters. Firmware and migration guidance was rechecked on September 23, 2026. Updated that day: current standard releases, required new-seed user entropy, and the exact independent-dice exception. The status page now serves as the vendor's living incident record; it says a separate detailed technical postmortem remains in preparation.
- Galaxy Research, Coldcard exploit abates as total losses climb to at least 1,700 BTC
- Coinkite, Technical deep dive into the entropy issue
- Block Engineering, Predictable RNG fallback and 32-bit reseed in Coldcard firmware
- Coldcard, Current security status
- Coldcard, Migrate an affected seed
- Bitcoin Improvement Proposals, BIP 39