A firmware defect caused affected Coldcard hardware wallets to skip their hardware random number generator and fall back to a predictable software generator. Keys generated on affected firmware can be reconstructed offline. Coinkite's advisory, updated August 1, confirms every model is affected: Mk2 and Mk3 at roughly 40 bits of effective entropy and Mk4, Q and Mk5 at roughly 72 bits, against an intended 128. Galaxy Research confirms 1,596 BTC taken from roughly 7,300 addresses, just over $100M, with a suspected fourth wave that would raise the total to about 2,055 BTC. The exploit remains active.
The initial disagreement over whether current models were affected has resolved. Coinkite's advisory, updated August 1, now states that Mk4, Q and Mk5 are also affected, aligning with Block's July 30 analysis. If you read earlier coverage saying those models were safe, including our own first version of this page, that guidance is superseded. See our corrections log.
Both primary sources now agree on scope. They still quantify the residual entropy differently, so both positions are recorded below. Proof of Custody has not independently reproduced either analysis.
What determines exposure is the firmware version at the moment the seed was created, not when the device was bought.
A check tested whether a configuration setting existed rather than whether it was enabled. The check passed, the hardware random number generator was bypassed, and the firmware fell back to a software generator seeded from guessable values. On newer models a secure-element reseed exists but retains only four bytes. Coinkite added on August 4 that the defect sat at a boundary between two unrelated submodules, "not in the parent code, and not in the cryptographic or Bitcoin-specific logic that are the subject of most internal and third-party reviews", and that because the flag check looked correct it went unnoticed while its impact grew with every release. Its own disclosure record attributes the random-byte fallback to a library migration.
Coinkite's advisory, updated August 1, states that seeds generated on Mk4, Q and Mk5 before the fixed releases are also affected, with about 72 bits of entropy rather than the expected 128. Mk2 and Mk3 are estimated at about 40 bits. Block quantifies the newer-model weakness differently, reporting that the reseed contributes at most 32 bits. Both agree on scope; they differ on magnitude.
The affected range begins at firmware v4.0.1, released March 2021, and the defect remained in publicly readable open-source code for roughly five years.
Galaxy Research confirms 1,596 BTC, just over $100M at August 4 prices, taken from roughly 7,300 addresses across three attack waves plus fourteen smaller incidents. Galaxy states the total is based on victim reports and on-chain analysis and that it holds the figure with high confidence. Around 73 victims have come forward. Read "confirmed" as one firm's assessment corroborated by victim reports, not as audited or adjudicated: 73 reports anchor a pattern across roughly 7,300 addresses rather than validating each one.
A fourth wave would raise the total to approximately 2,055 BTC, around $130M. Galaxy assesses with medium-high confidence that it is substantially the work of the same attacker but states it has not been confirmed by any victim, and has deliberately kept it out of its headline figure. The exploit remains active. Earlier snapshots of roughly 1,367 BTC and roughly 1,816 BTC were accurate when published and are superseded.
Galaxy reports that roughly 90% of the stolen coins remain unmoved, including all of the coins taken in waves one to three. Galaxy offers two readings: the operator is waiting for scrutiny to fade, or has no viable way to launder a sum this visible. Separately, on-chain analyst Willy Woo puts the odds of partial recovery at 20 to 40%, likely taking years.
Unlike the earlier waves, sweeps in the suspected fourth wave signal replace-by-fee. A holder who sees their own address being swept in the mempool has a short window to broadcast a competing transaction at a higher fee and move the funds first. This is a narrow escape hatch, not a defence, and it only helps someone already watching.
Coinkite states it ran AI-assisted review against its critical codebases in the weeks before the exploit and that it "did not catch this vulnerability". After the incident it re-tested against frontier models, naming Kimi K3, Claude Fable and Codex 5.6, and reports that none of them caught it either. Its own disclosure record logs an enterprise AI firmware review on June 26, 2026, roughly a month before the theft began, that produced 85 candidate findings without surfacing this one. Coinkite recommends that teams relying on AI review of security-critical code test it specifically against build and submodule boundaries. This is the vendor's own account of its process and Proof of Custody has not verified it, but it is a rare public data point on where automated review currently fails: at the seams between components rather than inside the cryptography.
Alongside the August 4 update Coinkite published a page recording known public security research, coordinated disclosures, professional audits, internal findings and advisories affecting Coldcard devices: 23 events from 2019 to August 2026, of which 12 show public evidence of coordinated disclosure. It is vendor-maintained and therefore self-selected, but it is a real primary artifact and more than most hardware vendors publish. We are treating it as a research source rather than as an independent audit.
Coinkite states that the patched firmware prevents the issue for newly generated seeds and does not repair or restore security to a seed already generated on vulnerable firmware. Affected holders must generate a new seed on fixed firmware and move funds to it.
Coinkite states that funds are at risk if the seed was created without at least 50 independent, private dice rolls and the wallet is not protected by a strong, unique BIP-39 passphrase. Fifty fair rolls contribute at least 128 bits on their own, which is why that path is treated differently.
Coinkite destroyed its remaining inventory manufactured with the vulnerable firmware and halted shipment when the vulnerability was confirmed. It states that its legal team will coordinate as warranted with law enforcement across multiple jurisdictions, which is a conditional commitment rather than confirmation of an active investigation. Galaxy Research has referred roughly 600 suspected attacker addresses to US federal investigators, exchanges and compliance firms; no indictment, seizure or agency statement has followed. It has also pointed users to alternative devices while they decide next steps, naming Bitkey, Ledger, Trezor, Jade and BitBox. Bitkey is made by Block, the company that published the competing engineering analysis.
Scope is settled. These narrower questions are not, and they are worth keeping separate from the parts both sources agree on.
Each bit removed halves the work an attacker must do. The scale below is logarithmic in the only way that matters: every step down is exponentially cheaper to break.
The design target. Brute force is not merely impractical, it is physically impossible with any foreseeable technology.
Coinkite's estimate of the effective search space, published in its advisory updated August 1 2026, under its stated attack assumptions. Block quantifies the same weakness differently, reporting that the secure-element reseed contributes at most 32 bits.
Coinkite's estimate for the older models, where no secure reseed exists at all. Independent researchers demonstrated recovering keys from this population within minutes using commodity hardware.
Read this carefully. These are the vendor's own estimates “under current attack assumptions”, not measured constants. Block's independent analysis quantifies the newer-model weakness on a different basis and reaches a lower number. Practical search space depends on model, firmware, observable device state, and call history. Proof of Custody presents both as reported and attributed.
The defect belongs to one vendor. The lesson does not. Holders who had followed standard advice and built multisig wallets discovered that keys generated on several units of the same device were never independent: one firmware defect reached every key in the quorum at the same moment.
That is the difference between nominal distribution and genuine independence, and it is the reason we publish the Custody Independence Standard. Counting keys does not measure a setup. Counting the independent things that must fail does.
Every hardware vendor has an entropy path, and this one sat in publicly readable open-source code for roughly five years before anyone found it. The reasonable posture is not that one vendor had a bug. It is that entropy and vendor concentration are now first-order questions for every custody arrangement, including those that have not had an incident.
Our full treatment of what this means for holders is in Is your custody setup actually safe?
Proof of Custody, "Coldcard entropy failure" incident record, proofofcustody.io/incidents/coldcard-entropy-2026Every model is affected. Coinkite's advisory, updated August 1 2026, states that Mk2 and Mk3 on firmware v4.0.1 through v4.1.9 are affected at roughly 40 bits of entropy, and that Mk4, Q and Mk5 generated before the fixed releases are also affected at roughly 72 bits, against an intended 128. This aligns with Block's July 30 analysis. Coinkite's earlier preliminary position that Mk4, Q and Mk5 were unaffected has been superseded. SATSCARD, OPENDIME and TAPSIGNER are not affected.
No. Exposure depends on the firmware version at the moment the seed was generated. Updating firmware now does not repair a seed that already exists. A seed created on affected firmware and later imported into a different wallet, or used for another chain, carries the same weakness.
It depends on whether the keys are genuinely independent. If enough affected devices can reach the spending threshold on their own, the wallet is exposed, because those keys share one firmware and one entropy path. Multisig built from several units of the same affected model provides far less protection than the key count suggests.
A strong BIP39 passphrase reduces exposure because an attacker who reconstructs the seed still needs the passphrase. Your funds are then only as protected as that passphrase, so a short, reused, or guessable one offers little. This lowers risk rather than eliminating it.
Move deliberately rather than quickly. Confirm which model and firmware generated your seed, treat any affected seed as compromised regardless of where it now lives, and migrate to keys generated on an unaffected process. Never enter a seed phrase into any website or message, because phishing targeting affected holders is already circulating.