A five-year-old bug with a very quiet failure mode
The flaw traces back to March 2021, when Coldcard's production build configuration checked whether a hardware randomness macro existed in the codebase rather than confirming it was actually enabled. When the macro was off, key generation silently fell back to MicroPython's Yasmarang pseudorandom generator, seeded from the chip's unique ID and timer registers rather than genuine hardware entropy. Once that fallback initialized, it collected no additional randomness afterward, meaning the entire seed generation process ran on a small, effectively guessable set of inputs.
Different device generations inherited different degrees of the weakness. Mk2 and Mk3 units running firmware 4.0.0 through 4.1.9 carried roughly 40 bits of effective entropy; Mk4, Mk5, and the Q model carried roughly 72 bits before their respective fixed versions. Both fall dramatically short of the 128 bits a standard 12-word BIP-39 seed is supposed to guarantee, and the gap compounds because bits of entropy shrink the search space exponentially rather than linearly. On paper this was a five-year-old bug that sat quietly in a code path nobody had reason to revisit. In practice it sat undetected in production hardware wallets that customers trusted specifically because they were supposed to be air-gapped and immune to this exact category of failure, which is what makes the eventual discovery so consequential for the broader hardware security market.
How you steal Bitcoin without ever touching the wallet
The attack itself is a clean demonstration of what a reduced keyspace makes possible. Rather than attacking a device directly, the attacker generated large batches of candidate seeds on their own hardware, computed the wallet addresses each seed would produce, and compared those addresses against the public blockchain to find ones holding funds. Block's investigators described it as systematic enumeration, checking each candidate seed against every path it might have produced, run entirely offline and remotely.
Between 01:10 and 01:51 UTC on July 30, the attacker drained 1,082.65 BTC from 1,196 addresses across six blockchain blocks, a pace of roughly one address every two seconds sustained for the better part of an hour. Notably, 1,183 of those addresses used modern native segwit formats, meaning the flaw hit users who were following current best practice around address types, not just legacy holdouts running outdated wallet software. Investigators later traced two additional waves, bringing the confirmed total to 1,367.05 BTC, roughly eighty nine million dollars, from 4,585 addresses. Proceeds from the initial wave remain sitting untouched in four addresses, and Block has passed its findings to law enforcement, though no arrest or seizure has been reported.
The patch doesn't undo the damage already done
Coinkite, Coldcard's manufacturer, released emergency firmware on July 31 across the affected model lines. But the company has been explicit that the update fixes future key generation, not past exposure: any seed generated on vulnerable firmware remains within the weakened keyspace even after the device is updated, because restoring an old seed to new firmware carries the original weakness forward with it. Users have no way to determine after the fact whether their specific seed was generated under the flawed logic.
That leaves a large population of wallet holders in an uncomfortable position: the only safe remediation is generating an entirely new seed on patched firmware and migrating funds, which requires users to notice the advisory, understand its implications, and act before an attacker enumerates their specific address. Seeds generated using at least 50 fair, independent dice rolls are unaffected by this particular flaw, a detail that matters mostly to the small subset of users who use that method deliberately.
The scope confusion is its own lesson
Coinkite's initial guidance warned Mk3 owners specifically and suggested newer devices were unaffected. Block's independent analysis places Mk2, Mk4, Q, and Mk5 within scope as well, a discrepancy between vendor and researcher assessments that left users genuinely unsure which devices needed action in the critical hours after disclosure. When a vendor and an independent research team disagree publicly about the blast radius of a vulnerability, customers are left to guess, and guessing with hardware wallet security is exactly the failure mode this class of device exists to prevent.
For any organization evaluating hardware security modules, cold storage, or air-gapped signing devices as part of its own key management, the lesson generalizes past cryptocurrency. Hardware isolation is only as strong as the entropy source underneath it, and a build-time misconfiguration can defeat physical security guarantees just as thoroughly as a network-facing bug. If your vendor cannot tell you with confidence which of your keys were generated under which firmware version, you have the same exposure Coldcard customers have right now.
What CTOs managing key material should take from this
The specific failure, a check for presence rather than a check for enablement, is a pattern worth auditing in your own build and configuration systems, well beyond hardware wallets. Feature flags, security controls, and compliance settings that are checked for existence rather than for the correct value are a recurring source of silent security regressions, and they are the kind of bug that static analysis and code review routinely miss because the code technically runs without error.
The second lesson is about entropy provenance. Any system generating cryptographic key material, whether in a hardware wallet, an HSM, or a cloud KMS, should be able to prove which entropy source was actually used at generation time, not just which source was configured. If that provenance is not logged and verifiable, you are trusting a fallback path you have never tested, and as this incident shows, that fallback can sit quietly for years before someone finds a way to enumerate it.
