The Coldcard RNG Bug: What Actually Happened, What's Actually At Risk, and Exactly What To Do Right Now

• The short version
• Coinkite’s response: “We fell short”
• Wait — how bad is “weaker randomness,” actually?
• How did a bug like this survive in open-source code for years?
• What you need to do right now
• Two habits worth keeping permanently, not just this week
• If you’re reading this and thinking “I’ll deal with it later”

I’ll get straight to it, because if you’re reading this with a Coldcard in your hand, every minute you spend on preamble is a minute your funds might be sitting on a weak key.

On July 30, Coinkite disclosed that recovery phrases generated on certain Coldcard firmware may not be as random as they were supposed to be. On August 1, they updated that advisory with harder numbers and a wider list of affected models. This post walks through both: what actually broke, why nobody caught it sooner, and the exact steps to get your funds safe.

Let’s break it down.

§The short version

A bug in how Coldcard generated randomness meant that, on certain firmware versions, your recovery phrase could have been drawn from a much smaller pool of possibilities than it should have been. Smaller pool means an attacker has to guess far fewer combinations to potentially find your private key.

This is not a bug you fix by updating. Updating stops new seeds from being weak. It does nothing for a seed that was already generated on the broken firmware: that seed is what it is, permanently, until you move to a new one.

Affected:

• Coldcard Mk3, firmware 4.0.1 through 4.1.9

• Coldcard Mk4, Mk5, and Q, on certain pre-fix Standard and Edge releases

Not affected: TAPSIGNER, OPENDIME, and SATSCARD — they run different codebases entirely.

Fixed firmware is out now for every affected model and release track (Mk3: 4.2.0+; Mk4/Mk5 Standard: 5.6.0+; Q Standard: 1.5.0Q+; Mk4/Mk5 Edge: 6.6.0X+; Q Edge: 6.6.0QX+).

If you already have a Coldcard in hand, this is not a “read it later” situation. Update the firmware, generate a fresh seed, and migrate. I’ll walk through exactly how below.

§Coinkite’s response: “We fell short”

Before we get into the technical details, it’s worth pausing on how Coinkite itself has handled this, because it matters for how much you can trust what follows, and because part of what they’re asking for is help spreading the word.

NVK, Coinkite’s founder, posted a public statement addressed to Coldcard users and the wider Bitcoin community. It’s a genuine apology, not a PR-massaged non-apology, and it’s worth reading in full on X… but here’s the shape of it.

He opens by saying the team is “heartbroken” about the disclosure, and that securing the bitcoin held by millions of people is meant to be the company’s core responsibility… one they acknowledge they fell short on this time. He’s explicit that Coinkite doesn’t store customer information, which is why they’re leaning on the community to help reach affected users directly, especially the people who aren’t watching crypto Twitter right now and may not know there’s anything to act on. His ask, verbatim in spirit: if you know a Coldcard owner, make sure they see this, because every hour matters.

On what happens next, a few specifics stand out:

• The hotfix ships today, and it removes the vulnerable software fallback path entirely: but as covered above, that only protects seeds generated after the fix. Anything generated before still needs to be individually migrated.

• A full technical postmortem is coming, but not yet. Coinkite says they’d rather be accurate than fast on the writeup of how the bug got into the codebase and why their own review missed it, even knowing people want answers immediately.

• They’re committing to support affected users who want to file a police report, pursue an insurance claim, or run their own investigation: including written incident summaries and cooperation with on-chain investigators and law enforcement.

• A broader warning to other developers, not just Coldcard users: Coinkite frames this as an early, sober example of a new reality… AI-assisted code review can now surface latent bugs faster than even experienced human auditors catch them, and any codebase that’s ever been public should be assumed to already be under that kind of scrutiny, from attackers and defenders alike.

That last point connects directly to what actually happened in the code… which is where we’re headed next.

§Wait — how bad is “weaker randomness,” actually?

This is the part that’s easy to either panic about or wave off, so let’s put real numbers on it.

Coinkite estimates the effective search space fell to around 40 bits on Mk3, and around 72 bits on Mk4, Q, and Mk5 (which had some extra entropy mixed in from onboard secure elements as a kind of accidental backstop). For comparison, a properly generated 24-word seed is supposed to sit at 256 bits, and even a 12-word seed targets 128 bits.

Going from 128 bits to 40 bits isn’t “somewhat weaker.” It’s the difference between a lock with more possible combinations than there are atoms in the observable universe, and a lock an attacker with real compute could plausibly start grinding through. 72 bits is a meaningfully better spot than 40, but it’s still well under the 128-bit target the system was designed around.

There are two things that pull a specific wallet back out of the danger zone, and they matter a lot:

1. If you generated your seed using at least 50 independent, private dice rolls, you added your own real-world entropy on top of whatever the broken firmware was doing… Coinkite says they don’t consider seeds generated this way at risk from this bug alone.

2. If your wallet has a strong, unique BIP-39 passphrase: not a short one, not a reused one, not something quoted from a book… that passphrase effectively creates a different wallet on top of the seed, which meaningfully reduces the immediate exposure.

If neither of those applies to you, treat it as what Coinkite itself calls it: not a theoretical risk, but a direct one.

§How did a bug like this survive in open-source code for years?

This is the part I find genuinely interesting, and it’s worth understanding even if you’re not technical, because it explains why “just read the code” isn’t the safety net people assume it is.

In 2021, Coldcard moved its elliptic-curve math over to libsecp256k1: the same cryptographic library Bitcoin Core itself trusts. Good call, on its own. Reinventing crypto primitives is how projects introduce worse bugs, not fewer.

But that migration required pulling in a supporting library, and somewhere in that process, the code path for generating a wallet seed quietly got rewired. Instead of pulling randomness from Coldcard’s own carefully built hardware random number generator, it started resolving to a fallback software random number generator that shipped inside MicroPython… a generator that was never meant to be cryptographically strong, and was originally written for a completely different purpose.

Here’s the part that made it invisible to review: both the real hardware generator and the fallback software generator exposed the exact same function signature. Anyone auditing the code could see the well-built hardware RNG sitting right there in the codebase, confirm it looked correct, and never realize the actual seed-generation path wasn’t calling it at all. The right code existed. It just wasn’t the code being used.

Buried underneath that was a second, smaller bug… a preprocessor check that was supposed to stop the build if the hardware RNG wasn’t properly wired in. It used #ifndef, which only checks whether a setting is defined at all, not whether it’s set to a meaningful value. Coldcard’s build had that setting explicitly defined as zero. Technically “defined.” The safety check that should have caught this passed right over it.

Two quiet, individually-plausible mistakes, stacked on top of each other, in code that’s been public the entire time.

Coinkite’s own words on how this finally surfaced: they’d run one of the leading AI models over their codebase for a security review just weeks earlier, and it didn’t catch this. Their working theory is that someone else did (using AI review tools on the same public source) and found what their own scan missed. As they put it, both attackers and defenders have access to the same tools now, and this time, that cut against the defenders first.

§What you need to do right now

The steps differ slightly depending on your model, so treat this as the general shape… and check Coinkite’s official advisory for your exact firmware.

1. Update to the fixed firmware before you generate anything new. Don’t skip this. Generating a “new” seed on old, broken firmware doesn’t fix anything.

2. Generate a completely new seed. Do not restore your old recovery phrase. This is the step people get wrong under stress. Restoring your old phrase into a new wallet just carries the same potentially weak key forward. You want the device to generate a fresh one from scratch.

3. Verify everything on the device screen, not just your phone or laptop. Confirm your new wallet fingerprint and a receive address directly on the hardware. If it doesn’t match what your computer shows, stop and figure out why before you send anything.

4. Send a small test transaction first. Wait for confirmation. Check that it shows up from a completely fresh session… not the tab you were already looking at. Only then move the rest.

5. Don’t destroy your old backup yet. Hold onto it until the new wallet is fully verified and the old one is confirmed empty… including any small leftover amounts, unconfirmed transactions, or other asset types you might have parked there. Destroying it too early, while any balance remains, makes that balance permanently unrecoverable.

6. Once you’re fully confirmed migrated, retire the old phrase for good. Shred or burn a paper backup. Physically destroy or restamp a metal one. Never reuse it, never enter it into a website “checker” tool, never import it into another wallet again… even years from now.

§Two habits worth keeping permanently, not just this week

Whatever hardware wallet you land on after this, carry these forward:

Verify on-device, every time. Not on the app, not on the browser… on the actual screen of the hardware wallet, before you approve anything. This entire bug is a reminder that software you didn’t write and can’t fully audit yourself is standing between you and your keys at every other layer. The device screen is the one thing an attacker can’t quietly rewrite from a browser tab.

Firmware only comes from official sources. An email offering you a firmware update (however official it looks, whoever it appears to be from) is a phishing attempt. Full stop. Go to the manufacturer’s site directly, every time.

§If you’re reading this and thinking “I’ll deal with it later”

Please don’t.

This isn’t a slow-burn issue where waiting a week costs you nothing. If your seed was generated on affected firmware and you don’t have the dice-roll or passphrase protection described above, the exposure is live right now, not theoretical. The fix isn’t complicated (update, generate fresh, verify, migrate, in that order) but it does require you to actually sit down and do it today.

And if you know someone holding a Coldcard who isn’t the type to see this on crypto Twitter: a parent, a friend who set up a hardware wallet three years ago and hasn’t thought about it since, someone who did everything right by getting off an exchange and just hasn’t been keeping up with advisories… this is the post to forward them. Being “less online” shouldn’t be the reason someone’s savings are the ones left exposed.

Coinkite has said this plainly themselves: they don’t store customer data, so they can’t reach affected users directly. The community is the distribution channel here. Forwarding this to one person who wouldn’t have otherwise seen it is a genuinely useful thing to do today, not just a nice gesture.

Move slowly, verify everything, and get it done.

For the most current information, follow Coinkite’s official updates at blog.coinkite.com and NVK’s statement on X. This post reflects the advisory as of August 1, 2026, and details may continue to evolve as Coinkite’s technical postmortem is finalized.