--- title: COLDCARD's RNG flaw let attackers drain wallets that... description: A critical firmware vulnerability in COLDCARD hardware wallets (Mk2 through Q versions, dating back to 2021) caused devices to silently fall back to Yasmarang,... canonical: https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: COLDCARD's RNG flaw let attackers drain wallets that never touched the internet | daily.dev og:description: A critical firmware vulnerability in COLDCARD hardware wallets (Mk2 through Q versions, dating back to 2021) caused devices to silently fall back to Yasmarang,... og:url: https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5 og:image: https://api.daily.dev/og/posts/UqAD1obK5.png og:image:alt: COLDCARD's RNG flaw let attackers drain wallets that never touched the internet og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # COLDCARD's RNG flaw let attackers drain wallets that never touched the internet **[Trends](https://daily.dev/sources/trends)** · 2 min read · 1 upvotes · 0 comments ## Summary A critical firmware vulnerability in COLDCARD hardware wallets (Mk2 through Q versions, dating back to 2021) caused devices to silently fall back to Yasmarang, a deterministic software RNG, instead of the STM32 hardware RNG. Because deterministic RNGs are predictable, attackers could reconstruct wallet seeds offline and drain funds without physical access. Estimated losses range from $88.6 million to over $130 million across thousands of addresses, exploited by at least a dozen hacker groups. Victims who followed all best practices — air-gapped devices, never exposing seed phrases — were still affected. Firmware patches are available, but they do not fix already-generated seeds; users must generate new seeds on patched firmware and migrate funds. Seeds supplemented with 50+ dice rolls are considered safe from this specific flaw. ## Content Hardware wallets exist for one reason: to make remote theft impossible. ColdCard just broke that assumption, and the community is still processing it. The bug is embarrassingly simple in hindsight. ColdCard's MicroPython firmware had two random number generators sharing the same function name. A flag meant to disable the weak built-in RNG was set to zero instead of being left undefined, so an `if not defined` check passed and the weak RNG ran instead of the secure hardware one. On bare metal with no OS, MicroPython's fallback RNG pulled from the chip serial number and a timer — both deterministic, both recoverable. Attackers looped through every possible combination offline, derived private keys, matched them against on-chain addresses, and drained wallets. No physical access required. The bug dates to 2021. The numbers vary by source — $88M, $115M, $130M — but the range of 1,367 to 1,600+ BTC stolen across 4,500 to 7,000+ wallets is consistent across reports. Affected firmware covers Mk2/Mk3 versions 4.0.1 through 4.1.9 and several Mk4, Mk5, and Q versions before recent patches. Victims who noticed in time faced a second problem: the mempool. Attackers could front-run rescue transactions with higher fees. The only workaround was submitting directly to mining pools to bypass the public mempool entirely. The passphrase question is getting a lot of attention. The short answer: it helped, but not as much as people hope. A passphrase and a compromised mnemonic don't add their security budgets together — the passphrase becomes the *only* security budget. A PIN or single common word falls within cracking range for a modest GPU farm within months. Three genuinely random diceware words push it past feasibility. But the passphrase was designed for physical theft, not RNG failures, and Coinkite is recommending migration regardless. Kraken's CSO is calling for cross-industry hardware audits. Bitcoin developers froze the BIP-110 soft fork in response. The broader reaction is less anger at Coinkite specifically and more a queasy recognition that "offline" and "secure" were never the same thing. Firmware updates are available but don't fix already-generated seeds. If you're on affected firmware, the only real fix is generating a new seed on a patched device and moving funds. ## Questions this post answers ### What caused the ColdCard hardware wallet RNG vulnerability that let attackers steal bitcoin? Two random number generators in ColdCard's MicroPython firmware shared the same function name, and a flag meant to disable the weak built-in RNG was set to zero instead of left undefined. This made an 'if not defined' check pass, so the weak RNG ran instead of the secure hardware one, pulling entropy from the chip serial number and a timer, both of which are recoverable offline. _Track hardware wallet security disclosures like this on daily.dev before trusting a device with real funds._ ### Which ColdCard firmware versions are affected by the RNG vulnerability? Affected firmware covers Mk2 and Mk3 versions 4.0.1 through 4.1.9, plus several Mk4, Mk5, and Q versions released before the recent patches. Updating firmware alone does not fix wallets whose seeds were already generated on vulnerable firmware; the only real remedy is generating a brand new seed on a patched device and migrating funds. _Developers auditing crypto wallet dependencies can follow version-specific advisories like this on daily.dev._ ### Does adding a passphrase protect a bitcoin wallet if the seed was generated with a weak RNG? A passphrase helps but does not add to the compromised seed's security budget, it becomes the only security budget. A PIN or single common word is crackable by a modest GPU farm within months, while three genuinely random diceware words push cracking past feasibility. Passphrases were designed against physical theft, not RNG failures, so migration to a new seed is still recommended. _Anyone weighing passphrase strength for wallet security can compare real-world cracking analyses like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 74 comments across hackernews (as of 2026-09-13). **TL;DR:** The community is highly critical of the Coldcard RNG vulnerability writeup and the underlying engineering failures, with expert commenter nullc providing a detailed correction of the root cause (an #if vs #ifndef mixup across repos) and broader discussion of why such bugs are so hard to detect and prevent. **Sentiment:** 5% positive · 35% mixed · 60% skeptical **The case for** - Using binary analysis alongside source review could catch this class of bug more reliably, since the dead code path would be absent from the compiled binary. - RFC 6979 deterministic signing mitigates some RNG bias concerns for DSA nonces in this context. - Fault injection testing (NOPing out the HWRNG and verifying failure) would have been an effective QA method to catch this. **The pushback** - The article misidentifies the root cause — the real bug is an #if vs #ifndef mixup across two separate repositories, not a simple flag change. - Insecure PRNG fallbacks in cryptographic code masked the failure and made it nearly undetectable through standard randomness testing. - The 1534-line commit with a 5-character message ('runs') reflects systematically poor code hygiene from the developer involved. - Using MicroPython for cryptographic operations on a microcontroller is considered deeply inappropriate by embedded developers. - The MK4+ 'fix' of XORing in another insecure PRNG further masked the bug without correcting it, and discards entropy unnecessarily. - Even open-source review failed to catch this, partly because the relevant code was split across multiple repositories. **By community** - hackernews (skeptical): Commenters, led by nullc, are sharply critical of both the article's technical accuracy and the underlying engineering practices, while debating broader lessons about RNG security, commit hygiene, and the limits of source-code review. **Hottest debate:** Whether the developer responsible was merely inexperienced/negligent or potentially acting maliciously, and whether the bug could have been intentionally introduced. **Open questions** - Are there still vulnerable coins on MK4+ devices that have not yet been rescued or stolen? - How fatal is the MP_EFAULT error condition in practice — could the emergency fix deployment itself cause device instability? - Why does the MK4+ code hash 64 bits of TRNG output and then discard half the entropy before XORing? - Should MISRA C include a directive specifically addressing definedness-vs-value check errors? **Highlights** > This writeup isn't very good and misses/misunderstands the programming error that leads to the flaw. I'm commenting because I think it's important to understand the issue. The article would have you think that the change in question was a tiny change to a flag to make it compile, but in reality the commit in question is a 1533 line addition of the entire RNG infrastructure. The fundamental cause is a mixup between a value test and a definedness test. Coldcard attempted to replace the micropython wrapper on the hardware TRNG, apparently in order to provide a more aggressive handling of fault/error conditions. The micropython hwrng code is gated by an #if check, the replacement HWRNG code is gated by an ifndef. So "#define MICROPY_HW_ENABLE_RNG (0)" deactivated the micropython implementation but failed to activate the internal one (which was #ifndef MICROPY_HW_ENABLE_RNG ... which didn't fire because MICROPY_HW_ENABLE_RNG was _defined_). This was easier to miss because the usages weren't only in different files-- they were in different repositories. There is a more abstract point to make that in cryptographic software the absence of a secure randomness source (the STM32 TRNG) should never fall back to an insecure source (a trivial PRNG which might have only had on the order of 20-bits of uncertainty in its input). But the code that had the fallback was micropython which was not authored by the coldcard creators and is presumably not intended for cryptographic applications... In later code (for MK4+ devices) the issue was further masked without being corrected by xor-ing in another insecure PRNG seeded by 32-bits from another TRNG. ... itself acting like an additional insecure fallback. (Why it first hashes 64-bits of TRNG output then throws away half the entropy is a mystery...) RNG failures can be difficult to detect because the real randomness and a PRNG are indistinguishable by any simple tests of the output. I understand the coldcard developers ran extensive tests on the randomness generated by these devices-- they may well have been just testing the PRNG. It's something of a "color of your bits" issue ( https://ansuz.sooke.bc.ca/entry/23 ). The same sort of issue happens at multiple levels of the stack, e.g. IIRC the STM32 TRNG itself does some kind of whitening that could have the same effect of concealing an RNG failure. The existence of insecure fake randomness in the code at all was a red flag that had been noted previously -- though the really bad one was hidden away in the micropython code and not even obviously at play. I think this is a rare case of a bug that would be more easily found from binary analysis than review of the source code (e.g. no access to the STM32 TRNG at all). Without these fallbacks the failure to use the TRNG would have been immediately detected by the developers (e.g. when every attempt generated the same seed), and a review could be validated by fault injection (NOP out the hwrng and verify that the test fails). > — [nullc on hackernews · 6 comments](https://news.ycombinator.com/item?id=49141886) > This flaw would probably be easier to find from the binary: the source itself was misleading, but if you analyized the binary you'd find that there was no access to the hwrng at all (assuming the dead code got eliminated by the compiler) or that the only function that accessed it was never called. One lesson out of this is that now that AI has made a certain grade of review cheap is that it would be useful to perform security review both against the source code and against the resulting binary. > — [nullc on hackernews](https://news.ycombinator.com/item?id=49146659) > I have absolutely no interest in defending this code-- and already considered it untrusthworthy before any of this. But in the interest of accuracy: > It does a memcpy of a minimum of 4 bytes This is a common misreading of MIN(). MIN(4,x) is a number that is a MAXIMUM of 4, not a minimum. Count is the number of bytes remaining in the buffer. The input to the copy is a 4-byte word. min(4,count) will produce a number 0-4 which is always equal to or less than count. The copy will not overflow the buffer or overrun the input: If count is 3, for example, then here will be 3 and it will copy 3 bytes. > believe it errors out if the HWRNG returns the same value twice. That's actually a thing that can legitimately happen. "0" is also a legitimate output. It's been a while since I looked but I believe the STM32 manual advises you to throw away data when this happens, because the rng is updated async with the processor and reads that are too fast will produce 0s or duplicate values. Entropy loss from doing so is generally negligible. Were it me I'd read enough into a cryptographic hash to render the output cryptographically close to uniform and not have to worry about it further. (particularly since some uses of cryptographic numbers are extremely sensitive to even small biases) I do wonder how fatal MP_EFAULT actually is...-- on a device like this being jumpy at failing the RNG is reasonable, but if it bricks the device (for example) that would be too much for a condition that (IIRC) the datasheet says can happen. If that error is worse than causing a reboot then it might be the case that their emergency fix deployment might have the effect of causing problems by deploying never-actually-tested code into the wild. When I initially looked at this code before finding the flaw I was somewhat surprised that this test didn't produce spurious failures. [Maybe someone who isn't traveling and on vacation might want to trace out that error condition, -- and check my vague recollection of the STM32 datasheets, as I could be remembering some other part] > — [nullc on hackernews · 1 comments](https://news.ycombinator.com/item?id=49146167) > Although I might disagree with the style of the write up, I think it is right that there are weak engineering practices applied: - not enough information provided in commit message. - this change ought to have been split into smaller chunks (e.g. introduce indirection whilst code continues to use hardware) - limited (automated) testing - potential confusion by the author over C concepts - additional complexity which could have been hidden behind a cleaner interface rather than using defines I agree about your points about: - defines over multiple repo's made this more complicated that was necessary. - fault injections would have been the appropriate way to test this (or maybe mocks) - testing of randomness needs careful design, e.g. RNG seeding can be a good way Taking a step back, we as a community of excellence need to emphasise that this isn't a criticism about the person/author. There needs to be a clear analysis of what went wrong whilst being kind to the person/people involved. > — [egwor on hackernews](https://news.ycombinator.com/item?id=49143450) > Ironic: > NEW POLICY If I don't know you, I don't merge you! Thanks XZ! https://github.com/switck/libngu > — [anonymars on hackernews](https://news.ycombinator.com/item?id=49144132) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49140405) · 48 points · 74 comments ## Similar posts on daily.dev - [They Didn’t Steal Your Keys. They Regenerated Them.](https://daily.dev/posts/they-didn-t-steal-your-keys-they-regenerated-them--zeogglmg2) · Coins Bench · 2 upvotes · 1 comments --- Tags: [#security](https://daily.dev/tags/security), [#cryptography](https://daily.dev/tags/cryptography) [View this post on daily.dev](https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"COLDCARD's RNG flaw let attackers drain wallets that never touched the internet","url":"https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5"},"datePublished":"2026-08-04T21:04:15.986Z","dateModified":"2026-09-13T19:43:19.912Z","description":"A critical firmware vulnerability in COLDCARD hardware wallets (Mk2 through Q versions, dating back to 2021) caused devices to silently fall back to Yasmarang,...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/406f4ba0a26fd17fd51c1190c23e1eb3?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/406f4ba0a26fd17fd51c1190c23e1eb3?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Trends","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Trends","logo":"https://media.daily.dev/image/upload/s--ZfSp3asX--/f_auto,q_auto/v1780996004/logos/trends?_a=BAMAMiWQ0","url":"https://daily.dev/sources/trends"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,cryptography","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Trends","item":"https://daily.dev/sources/trends"},{"@type":"ListItem","position":3,"name":"COLDCARD's RNG flaw let attackers drain wallets that never touched the internet"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/coldcard-s-rng-flaw-let-attackers-drain-wallets-that-never-touched-the-internet-uqad1obk5#faq","mainEntity":[{"@type":"Question","name":"What caused the ColdCard hardware wallet RNG vulnerability that let attackers steal bitcoin?","acceptedAnswer":{"@type":"Answer","text":"Two random number generators in ColdCard's MicroPython firmware shared the same function name, and a flag meant to disable the weak built-in RNG was set to zero instead of left undefined. This made an 'if not defined' check pass, so the weak RNG ran instead of the secure hardware one, pulling entropy from the chip serial number and a timer, both of which are recoverable offline. Track hardware wallet security disclosures like this on daily.dev before trusting a device with real funds."}},{"@type":"Question","name":"Which ColdCard firmware versions are affected by the RNG vulnerability?","acceptedAnswer":{"@type":"Answer","text":"Affected firmware covers Mk2 and Mk3 versions 4.0.1 through 4.1.9, plus several Mk4, Mk5, and Q versions released before the recent patches. Updating firmware alone does not fix wallets whose seeds were already generated on vulnerable firmware; the only real remedy is generating a brand new seed on a patched device and migrating funds. Developers auditing crypto wallet dependencies can follow version-specific advisories like this on daily.dev."}},{"@type":"Question","name":"Does adding a passphrase protect a bitcoin wallet if the seed was generated with a weak RNG?","acceptedAnswer":{"@type":"Answer","text":"A passphrase helps but does not add to the compromised seed's security budget, it becomes the only security budget. A PIN or single common word is crackable by a modest GPU farm within months, while three genuinely random diceware words push cracking past feasibility. Passphrases were designed against physical theft, not RNG failures, so migration to a new seed is still recommended. Anyone weighing passphrase strength for wallet security can compare real-world cracking analyses like this on daily.dev."}}]} ```