Coinkite shipped Coldcard firmware 4.0.1 in March 2021. Somewhere in the build configuration sat a macro that had been defined and then set to zero, along with a preprocessor guard that only bothered to check the first half of that. The build saw a definition, concluded the hardware random number generator was wired up, quietly linked against a software fallback instead, and reported success. Nothing warned anybody. It went out the door and stayed out the door for five years and four\u00a0months.<\/p>\n
Shortly after 1am UTC on 30 July 2026, an attacker started sweeping. Galaxy Research clocked the first wave at 1,082 BTC out of 1,196 addresses in forty-one minutes<\/a>, which is where the $38 million number<\/a> in the early headlines came from\u200a\u2014\u200athat was a subset, roughly 594 BTC taken from about 500 single-signature wallets inside twenty-five minutes of the larger sweep. The totals have not stopped moving since. Galaxy now has about 1,596 BTC confirmed across three waves<\/a>, near $100 million, plus a suspected fourth that would put it around 2,055 BTC and $130 million. Forbes, counting a slightly different address set, reported 1,816 BTC from more than 5,200 addresses. Alex Thorn, who runs research at Galaxy, said this week that at least fifteen separate attackers have worked the same flaw, which is a detail worth sitting with: once the bug was public, the search space was small enough that this became a race rather than a\u00a0heist.<\/p>\n I\u2019d take all of those figures as provisional. Victim reports are still arriving and each one lets analysts label attackers they\u2019d otherwise have\u00a0missed.<\/p>\n The mechanics are less exotic than \u201chardware wallet hack\u201d suggests. Coldcard\u2019s firmware calls a function to get randomness, and the codebase contained two implementations of that function with identical signatures: the one Coinkite wrote for the STM32 hardware generator, and a fallback inherited from MicroPython. Coldcard\u2019s production build deliberately switched off MicroPython\u2019s own hardware RNG, since the device brought its own. That was fine. Checking for the switch by asking whether the macro existed rather than what it contained was not fine, and because both functions looked the same to the linker, the compiler had no reason to complain.<\/p>\n What it fell back to was MicroPython\u2019s Yasmarang generator, initialised once on first call and never reseeded afterward. Every output after that is a deterministic state transition, so if you can pin down where the state started you can replay the whole sequence offline. Block\u2019s Bitcoin engineering team<\/a>, which published early and said plainly that it was doing so because active exploitation was under way, found that on Mk2 and Mk3 devices no cryptographically generated secret entered the generator at all. Mk4, Mk5 and Q pull in data from a secure element, but the reseed retains only four bytes, leaving at most 2\u00b3\u00b2 distinguishable output streams once you fix the fallback state and call\u00a0history.<\/p>\n Coinkite\u2019s own estimate<\/a> is roughly 40 bits of effective entropy on Mk3, around 72 on the newer models, against the 128 that a twelve-word BIP-39 phrase is meant to carry. Those numbers are easy to skim past. A 128-bit space holds about 3.4 \u00d7 10\u00b3\u2078 candidates and will not be searched by anyone with any hardware that currently exists or is credibly planned. Forty bits holds 1.1 trillion, which is a weekend on rented compute and a modest cloud\u00a0bill.<\/p>\n Nobody needed to touch a device. You enumerate candidate seeds, derive the addresses, and check them against the blockchain<\/a> to see which ones hold money. Bitcoin\u2019s public ledger, normally the thing that makes the system auditable, worked here as a free oracle telling the attacker which guesses had paid off. Chainalysis found the sweeps went after the largest balances first, which tells you the attacker had built a full candidate list before spending a single transaction fee.<\/p>\n Two consequences catch people out. Exporting a weak seed into a different wallet doesn\u2019t clean it, so anyone who migrated off a Coldcard years ago and assumed that settled the matter is still exposed. And installing the fixed firmware does not repair an existing seed<\/a>\u200a\u2014\u200aCoinkite has said this repeatedly and it is still the point that gets lost in summaries. The keys were generated weak. They stay weak. There is no patch for a number that has already been written\u00a0down.<\/p>\n Rodolfo Novak apologised on 31 July and took responsibility, which, given how many CEOs in this industry reach for the passive voice on days like that, is worth acknowledging. He also floated an explanation for how the flaw surfaced after half a decade of sitting in a public repository: Coinkite, he wrote, had to assume somebody had run AI over older versions of the firmware. He called it a \u201csober reality of the new AI paradigm\u201d and told other developers to assume their public code is already being read by both\u00a0sides.<\/p>\n Then came the detail that turned this from a Coldcard story into an industry one. Coinkite had run its own AI-assisted review of the same repository a few weeks earlier. It came back\u00a0clean.<\/p>\n Haseeb Qureshi at Dragonfly pushed the idea further, proposing a \u201cCost of Discovery\u201d measure\u200a\u2014\u200ahow cheaply a frontier model can reproduce a given bug\u200a\u2014\u200aand pricing this one at roughly \u201c$2 of AI hardening.\u201d<\/p>\n Most of the coverage has since treated the AI attribution as established. It isn\u2019t, and the gap between what is claimed and what is demonstrated is wide enough that I think anyone citing this incident should know where it sits. No evidence has established how the attacker actually found the bug. Coinkite\u2019s line is an assumption the company says it is obliged to make, which is a reasonable thing for a vendor to say and not the same thing as a\u00a0finding.<\/p>\n The demonstrations doing the rounds are weaker than the headlines they generated. The much-shared claim that a model located the flaw in two minutes traces back to a pseudonymous Reddit user scanning the code after disclosure, a point Tokenomist\u2019s data lead Tatsapat Saerejittima made to Cointelegraph, and pointing a model at a known, described, already-public defect is a categorically different exercise from finding it cold. Qureshi flagged the same problem himself, noting that an eight-minute Claude Code result may have been contaminated by web search, and offered a twenty-minute rediscovery by the open-source GLM 5.2 with search disabled as the cleaner figure. None of these runs were blind. None published methodology or false-positive rates. Twenty minutes with the answer in the training distribution is not twenty minutes of\u00a0search.<\/p>\n There\u2019s also a fair argument, which several engineers have made, that fixating on the AI angle lets an ordinary process failure off the hook. A macro-value check on a security-critical build path is a known bug class with known detection methods. Somebody could have caught this in 2021, or in any of the four years after. Ledger\u2019s Vincent Bouzon put the narrow version of the point well: what failed here was one manufacturer\u2019s entropy implementation, not the concept of self-custody, and the alternatives carry costs of their own that don\u2019t disappear because this week was\u00a0bad.<\/p>\n This firmware was open source. It was scrutinised by an unusually technical user base, on a Bitcoin-only device with a deliberately small attack surface, marketed and largely accepted as the serious option. If many eyes were going to make a bug shallow, the conditions were about as favourable as they\u00a0get.<\/p>\n The eyes were there. What was missing was any reason to spend a week of them re-reading a 2021 build configuration that had never caused a problem, and that\u2019s the economics that just changed, whether or not a model found this particular bug. Old code can now be read at a cost that rounds to zero, and crypto has an enormous inventory of exactly that: abandoned bridge contracts, forks of forks, libraries imported once in 2022 and never revisited, all of it public, all of it now cheap to examine by anyone with a few dollars and a motive. Coldcard is the most visible entry in a longer run of security failures this year<\/a>, not an\u00a0outlier.<\/p>\n The uncomfortable asymmetry is that a defender\u2019s AI review has to find everything and an attacker\u2019s has to find one thing, so a clean report buys the defender confidence he hasn\u2019t earned while a single hit hands the attacker a working exploit. Coinkite\u2019s review came back clean weeks before $100 million moved, into an address that has since filled up with pleas and messages written into the ledger by\u00a0victims<\/a>.<\/p>\n The specifics are model-dependent<\/a> and getting them wrong is costly, so this is the short version rather than a substitute for the advisory.<\/p>\n Affected: seeds generated on Mk2 and Mk3 firmware 4.0.1 through 4.1.9, Mk4 and Mk5 before standard 5.6.0 or Edge 6.6.0X, and Q before standard 1.5.0Q or Edge 6.6.0QX. Standard and Edge are separate release tracks, so a higher Edge number tells you nothing about whether the fix is in. Tapsigner, Opendime and Satscard run on different codebases and aren\u2019t affected.<\/p>\n Seeds you imported rather than generated on the device are fine. If you added at least 50 fair, independent, private dice rolls at setup, Coinkite doesn\u2019t consider that seed at risk from this issue alone, because your dice supplied the randomness the firmware didn\u2019t. A strong unique BIP-39 passphrase is a real second barrier, though a short or reused one is guessable and Coinkite still recommends moving. Multisig survives one compromised key; a quorum assembled entirely from post-2021 Coldcard seeds does not, and several people have discovered that distinction the hard\u00a0way.<\/p>\n Everyone else: update the firmware<\/a>, generate a fresh seed on the patched device, verify the backup and fingerprint, send a small test transaction, then move the\u00a0rest.<\/p>\n And read the advisory itself<\/a> rather than anybody\u2019s summary of it, including this\u00a0one.<\/p>\n Is my Coldcard affected?<\/strong> It depends on the firmware the device was running when the seed was first created, not when you bought the hardware. The affected range is Mk2 and Mk3 on 4.0.1 through 4.1.9, Mk4 and Mk5 before standard 5.6.0 or Edge 6.6.0X, and Q before standard 1.5.0Q or Edge 6.6.0QX. Check which release track you\u2019re on before comparing version numbers, because Edge and Standard number independently.<\/p>\n I\u2019ve installed the fix. Am I safe now?<\/strong> Not if your seed predates it. The hotfix corrects how new seeds are generated and does nothing to a seed that already exists, since the weakness was baked into the number the moment it was created. You need a new seed on patched firmware and a migration of\u00a0funds.<\/p>\n I moved my coins off the Coldcard a while ago. Does that help?<\/strong> Only if you also generated a new seed. Exporting the same recovery phrase into a different wallet carries the weakness with it, which is the detail Block\u2019s team went out of its way to emphasise.<\/p>\n Does a BIP-39 passphrase protect me?<\/strong> A strong, unique one is a genuine independent barrier\u200a\u2014\u200aan attacker who reconstructs the seed still can\u2019t reach that wallet without also guessing the passphrase. Coinkite is explicit that short, common, patterned or reused passphrases don\u2019t count, and recommends migrating regardless.<\/p>\n What about dice rolls?<\/strong> The flaw didn\u2019t touch entropy you supplied yourself. Coinkite\u2019s position is that at least 50 fair, independent, private rolls contributed enough randomness on their own that the resulting seed isn\u2019t at risk from this issue alone. Fewer than 50, or you can\u2019t remember, means\u00a0migrate.<\/p>\n Is my multisig safe?<\/strong> One compromised key in a quorum can\u2019t move funds, so multisig held up well in most setups. The exception is a quorum where every key was generated on a post-2021 Coldcard, which offers no such protection. Rotate enough keys to restore a secure\u00a0quorum.<\/p>\n How much was actually stolen?<\/strong> Galaxy Research has confirmed roughly 1,596 BTC across three waves, near $100 million, with a suspected fourth wave that would take it to about 2,055 BTC. Forbes counted 1,816 BTC from more than 5,200 addresses. The figures differ because analysts are clustering addresses by on-chain behaviour rather than proving each one came from a weak seed, and they\u2019re still being revised as victims come\u00a0forward.<\/p>\n Did AI really find the bug?<\/strong> Nobody has established that. Coinkite says it has to assume so, given the firmware was public for years, and the demonstrations circulating afterward all ran against a defect that was already disclosed. The interesting confirmed fact is the other direction: Coinkite\u2019s own AI-assisted review of the same code weeks earlier missed\u00a0it.<\/p>\n Are Coinkite\u2019s other products affected?<\/strong> No. Tapsigner, Opendime and Satscard are built on separate codebases. Coinkite has also said it destroyed remaining inventory carrying the vulnerable firmware.<\/p>\n Can the stolen bitcoin be recovered?<\/strong> The funds are visible and tracked by analytics firms, but visibility isn\u2019t recovery\u200a\u2014\u200athat depends on law enforcement and on the attacker eventually touching a regulated venue. Coinkite has said it will help affected users with police reports, insurance claims and independent investigations, and has not offered compensation.<\/p>\n Coldcard\u2019s Bug Hid 5 Years. AI Read the Code in Minutes.<\/a> was originally published in Coinmonks<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>","protected":false},"excerpt":{"rendered":" Coinkite shipped Coldcard firmware 4.0.1 in March 2021. Somewhere in the build configuration sat a macro that had been defined and then set to zero, along with a preprocessor guard that only bothered to check the first half of that. The build saw a definition, concluded the hardware random number generator was wired up, quietly […]<\/p>\n","protected":false},"author":0,"featured_media":210023,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-210022","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-interesting"],"_links":{"self":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/210022"}],"collection":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=210022"}],"version-history":[{"count":0,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/posts\/210022\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=\/wp\/v2\/media\/210023"}],"wp:attachment":[{"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=210022"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=210022"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mycryptomania.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=210022"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Coinkite\u2019s theory, and the part nobody has\u00a0proven<\/h3>\n
Why it matters even if Coinkite is wrong about the\u00a0cause<\/h3>\n
Migration notes<\/h3>\n
Questions people keep\u00a0asking<\/h3>\n