Coldcard Seed-Generation Vulnerability: What Happened, Are You Affected, What To Do

Read this first (30-second version)

• What happened: on 2026-07-30 Coinkite disclosed that a build-configuration mistake caused COLDCARD firmware to generate wallet seeds using a weak software random-number generator instead of the device’s hardware one. Coinkite shipped fixed firmware the next day, 2026-07-31.
• How long it was there: the regression entered the codebase with a library migration on 2021-03-01 and shipped in firmware v4.0.0 on 2021-03-17. That is roughly five years and four months.
• Who is at risk: anyone whose seed was generated on the device while affected firmware was running. Mk2 and Mk3 seeds are worst — roughly 40 bits of real randomness instead of 128. Mk4, Mk5 and Q seeds are around 72 bits. Both are breakable.
• The part people keep getting wrong: installing the patch does not fix a seed you already have. Coinkite’s advisory states it plainly: “Updating the firmware does not change or repair an existing seed.” If your seed was created under affected firmware, the only fix is a new seed and a move of funds.
• Money is actually gone. Galaxy Research attributes roughly 1,596 BTC — over 100 million US dollars — to this flaw with high confidence as of 2026-08-04, and reports at least fifteen separate attackers working independently.
• There is a second attack running right now that targets Coldcard owners specifically, by pretending to be a Coldcard security audit. Read that section before you touch anything.

What Coinkite disclosed

Credit where it is due: Coinkite disclosed this themselves, published a technical backgrounder explaining exactly how the mistake was made, and released fixed firmware for every affected model within one day. That is the behaviour you want from a vendor when something goes wrong. It does not undo the damage, and it does not make the affected seeds safe — but the disclosure was theirs and the fix was fast, and both facts belong in any honest account of this.

What actually went wrong, in plain language

Every Bitcoin wallet starts with a big random number. Everything else — your seed words, your keys, your addresses — is derived from that one number by public, published math. The math is not secret. The randomness is the entire secret. If an attacker can guess the starting number, they get every key you will ever have, and they do not need to touch your device to do it.

COLDCARD has a dedicated hardware randomness source in its chip, which is the right thing to use. The firmware was supposed to use it. Instead, a one-line mistake in a build setting meant the code silently fell back to a small software random-number generator borrowed from MicroPython.

The mistake is worth understanding because it is so ordinary. The code checked whether a setting called MICROPY_HW_ENABLE_RNG was defined, rather than whether it was switched on. Coinkite had defined it — and set it to zero, meaning “off”, because they supply their own hardware randomness. Defined-but-zero passed the check. In Coinkite’s own words in their technical backgrounder: “We defined that macro as zero, so the #error did not stop the build.” The safety net that was supposed to catch exactly this never fired, and the build shipped.

The fallback generator was then started from information that is not secret: the chip’s serial number, a timer counter, and clock registers. It never collected any fresh randomness afterwards. So instead of a number nobody could guess, the seed came from a small set of possibilities that a motivated attacker can simply run through, one after another, until the addresses match a wallet on the blockchain.

Block’s Bitcoin engineering and security teams, working with anonymous researchers, published an independent analysis the same day describing a second, related weakness on the newer models: the attempted top-up of randomness from the secure element only updates a single 32-bit value, which is far too small to rescue the situation.

Why “40 bits” and “72 bits” are both broken

A seed is supposed to have 128 bits of randomness at minimum. “Bits” here are a measure of how many possibilities an attacker has to work through — each extra bit doubles the work.

• 128 bits is about 3.4 × 10³⁸ possibilities. Nobody is getting through that.
• 72 bits is about 4.7 × 10²¹. That sounds enormous, and it is 2⁵⁶ times — roughly 72 quadrillion times — easier than 128. Wizardsardine describe sweeping this range as “somewhere between ‘expensive’ and ‘cheap’ depending on what the attacker already knows.”
• 40 bits is about 1.1 × 10¹². Wizardsardine put it bluntly: “40 bits is swept in a matter of hours on ordinary hardware.”

This is not a theoretical weakening. CoinDesk reported the first observed sweep clearing roughly 500 wallets in a window of 25 to 41 minutes. If you want the full picture of what these numbers mean and why 128 is the floor rather than a nice-to-have, we wrote a separate explainer: what entropy actually is, and why 128 bits matters.

Affected versions

The version that matters is the one that was running when you created the seed

Affected firmware table

Source: Coinkite advisory, 2026-07-30 (updated 2026-08-01). Effective-entropy figures from Coinkite’s technical backgrounder.

Model	Affected firmware	Fixed in	Effective randomness	Should have been
Mk2 / Mk3	4.0.1 – 4.1.9 (Block’s writeup gives the range as 4.0.0 – 4.1.9; assume 4.0.0 is affected)	4.2.0	~40 bits	128 bits
Mk4 / Mk5 (standard)	before 5.6.0	5.6.0	~72 bits	128 bits
Mk4 / Mk5 (Edge)	before 6.6.0X	6.6.0X	~72 bits	128 bits
Q (standard)	before 1.5.0Q	1.5.0Q	~72 bits	128 bits
Q (Edge)	before 6.6.0QX	6.6.0QX	~72 bits	128 bits
TAPSIGNER · OPENDIME · SATSCARD	Not affected — different codebases, per Coinkite.

There is a small discrepancy between the two primary sources on where the Mk2/Mk3 range starts — Coinkite says 4.0.1, Block says 4.0.0. We have not resolved it and we are not going to guess. Assume 4.0.0 is affected; it is the safe direction to be wrong in.

Note also that no CVE has been assigned to this issue as of 2026-08-06. If you are searching for a CVE number and finding nothing, that is why — not because the issue is unconfirmed.

You are NOT affected if…

This list matters as much as the one above. A large number of people are currently frightened about a device that never had this problem. If any of the following describes you, you do not need to move anything because of this flaw.

• You do not own a COLDCARD. This is a COLDCARD firmware issue. Trezor, Ledger, Blockstream Jade and Foundation Passport each published statements saying their devices are not affected, and each described a seed-generation design that mixes multiple independent randomness sources. We are reporting that they said it — those are vendor self-attestations, not independent audits, and we are not in a position to vouch for any of them. Links are in the sources section.
• Your seed was generated somewhere else and imported. If you created your seed on a different device, from dice, or in another wallet, and then typed or scanned it into the Coldcard, the Coldcard never generated it. This bug does not touch it.
• Your seed was created on fixed firmware or later — Mk2/Mk3 on 4.2.0+, Mk4/Mk5 on 5.6.0+ (Edge 6.6.0X+), Q on 1.5.0Q+ (Edge 6.6.0QX+). A device you set up after 2026-07-31 on current firmware is fine.
• You used dice. Coinkite’s own position: if you entered “at least 50 fair and independent rolls” when the seed was created, and those rolls stayed private, “we do not consider the resulting seed at risk from this RNG issue alone.” Fifty fair six-sided rolls carry about 129 bits of randomness on their own. Two conditions attached: the rolls have to have been genuinely fair and independent, and nobody else can have seen or kept a copy of the sequence. If you are not certain of both, Coinkite says migrate anyway.
• You have a TAPSIGNER, OPENDIME or SATSCARD. Different codebases. Not affected, per Coinkite.
• You have a Coldcard Mk1. Wizardsardine’s analysis states the Mk1 is unaffected because it never ran the firmware that contained the regression. Coinkite’s advisory does not list Mk1 either way; we are attributing this one to Wizardsardine rather than asserting it ourselves.

What was actually lost

Reported figures have climbed every day since disclosure, because analysts keep identifying additional waves. There is no single correct number, so here is the series with dates and sources attached. Read it as a trajectory, not a total.

Date	Reported figure	Attributed to
2026-07-31	594.48 BTC (~$38.3M) across roughly 500 wallets, swept in a 25–41 minute window	CoinDesk
2026-08-02	1,367 BTC (~$88.6M) across more than 4,500 addresses, in three waves	Galaxy Research, via CoinDesk
2026-08-04	1,596 BTC (over $100M) across roughly 7,300 addresses — three waves plus fourteen smaller incidents, stated at high confidence	Galaxy Research, via Crypto Times
2026-08-04	Up to 2,055 BTC (~$130M) if an unconfirmed fourth wave is included, stated at medium-high confidence	Galaxy Research, via crypto.news
2026-08-04	At least fifteen separate attackers now sweeping independently	Galaxy Research, via Crypto Times

That last line is the operationally important one. This is not one adversary who might get bored. Multiple unrelated parties have independently worked out how to enumerate these seeds and are racing each other through the address space. There is no waiting this out.

Before you do anything: the scam wave

Every large custody incident is followed within days by a second attack aimed at the frightened people, and this one is no exception. In some events the follow-on phishing takes more from victims than the original bug. Read this section before the migration section.

The specific campaign researchers have documented

Proofpoint identified an active phishing campaign impersonating a Coldcard security audit, reported by BleepingComputer on 2026-08-05. Documented details:

• Emails from compliance@coldcardteamnews.com — a lookalike domain, not Coinkite’s.
• Subject line “Hardware audit now available”, claiming “a coordinated security audit now underway across the COLDCARD device network.”
• A fake site at coldcardcompliance.com offering a “Security Verification & Incident Reporting Tool.”
• An artificial deadline of August 10 to create urgency.
• A download named Coldcard_Diagnostic_Tool.bat which installs ConnectWise ScreenConnect — legitimate remote-access software — behind a fake DocuSign printer-driver prompt, handing the attacker control of the victim’s computer.
• A real human staffing the fake site’s live chat, walking victims through the install.

Five rules that hold no matter who is asking

1. Never type, photograph, scan or paste your seed words into anything. Not a website, not an app, not a “checker”, not a support agent, not a spreadsheet, not a password manager, not a wallet you were sent a link to. There is no legitimate tool anywhere that needs your existing seed to tell you whether it is affected. None. The answer comes from the firmware version at creation time, and you already have that answer from the table above.
2. No hardware wallet manufacturer will ever email you a diagnostic program, ask you to install remote-access software, or need to see your screen. Not one. If someone is asking, they are stealing from you, and the fact that they are polite and patient about it is the tradecraft.
3. Type addresses by hand. Never click through. Go to coinkite.com or coldcard.com yourself, in a fresh tab, letter by letter. Do not use links from emails, DMs, search advertisements, or a post someone helpfully sent you. Search ads for wallet-related terms are routinely bought by drainers.
4. Ignore every deadline. “By August 10”, “within 24 hours”, “before the next wave” — manufactured urgency is the oldest tool there is, and it exists to stop you checking. Coinkite has not set a deadline. Nobody legitimate has.
5. Nobody credible will DM you first. If you post about this anywhere publicly, you will receive helpful private messages within minutes. Every single one is an attack. Support does not DM. Ask your questions in public, read the answers in public, and let the private offers of help rot in your inbox.

There is a sixth that is harder to hear: do not hire a “recovery service.” If coins have already been swept from an affected address, they are gone. No service can reverse a Bitcoin transaction. Companies that advertise otherwise are, without meaningful exception, running the second half of the theft.

What “generate a new seed and move funds” actually means

Plainly: you make a brand-new wallet with a brand-new seed on trustworthy randomness, and you send your Bitcoin from the old wallet to the new one, on-chain, as a normal transaction. There is no way to “repair” a weak seed. The starting number was weak, and everything derived from it inherits that. A new starting number means a new wallet.

Coinkite’s own steps

We are not going to write our own recovery procedure. Coinkite’s advisory contains a sequence, they know their device, and following their words rather than our paraphrase is the safer path. Their steps, as published:

1. Confirm fixed firmware is installed.
2. Generate a new seed on the updated device.
3. “Record and verify its backup before depositing funds.”
4. Verify a receive address on the device screen.
5. “Send a small test transaction and confirm that the new wallet works.”
6. Move the remaining funds only after the test succeeds.
7. “Keep the old backup until the migration is complete and confirmed.”

Read the advisory in full at Coinkite before you start. If you would rather generate the new seed somewhere other than on the same device, that is a reasonable instinct and Wizardsardine’s write-up recommends exactly that — but do it with something you already own and already know how to use. The middle of an emergency is the worst possible time to learn a new tool.

Things that will bite you

• Do not destroy the old backup yet. Coinkite says this and it is the step people skip. Until the new wallet is verified and the funds have actually arrived and confirmed, the old backup is your only way back from a mistake. Destroy it afterwards, not during.
• Verify the receive address on the device’s own screen before sending anything to it. A compromised computer can show you an address that is not yours. The device screen is the one display an attacker on your PC cannot rewrite.
• Send a small test amount first, and wait for confirmation. Yes, even though it feels slow. Especially because it feels slow.
• Think about the fee for thirty seconds. A transaction sent with too low a fee can sit unconfirmed for a long time, which is exactly the stress you do not need. Panic-paying an enormous fee is also a real cost. If you are unsure, ask in a public forum before you broadcast — never in a private message.
• Your new wallet may look empty when you restore it later. That is usually a derivation-path mismatch between wallet software, not lost money. We keep a reference for exactly this situation: Bitcoin Wallet Recovery & Derivation-Path Matrix.
• Write the new seed on something durable and check it letter by letter before funding it. A migration that ends in an unreadable or mis-transcribed backup has traded one loss for another. Background: Steel Seed Backup.
• Do not reuse the old passphrase on the new seed. New seed, new passphrase, if you use one at all.

If you are not technical and the amount is large

Some honest advice, given knowing it costs us nothing and helps you.

Moving a significant amount of Bitcoin between wallets under time pressure is the situation in which people make irreversible mistakes. If you are not confident doing it, get help from a person you already knew before this week — someone you can sit next to, in a room, with the hardware in front of you. Not someone who appeared in your notifications after the news broke. Not a service. Not a stranger who is very reassuring.

If nobody like that exists in your life, move slowly and use the test-transaction step religiously. Slow and correct beats fast and wrong. Note also that the attackers are working through address space — a wallet with a smaller balance is a lower-priority target than a large one, which buys some time, though it is not safety and should not be treated as a reason to delay.

What this does and does not say about hardware wallets generally

It would be easy, and wrong, to read this event as “hardware wallets are broken.” Here is what we think is actually supportable.

What it does say: a device you cannot audit can fail silently for years, and the failure can be in a part of the system where nothing looks wrong from the outside. Twenty-four English words look exactly the same whether they came from 256 bits of real randomness or forty. There is no light that turns red. Every user affected by this held a device that appeared, in every respect, to be working correctly.

What it does not say: that any particular alternative is safe. Every other vendor’s “we are not affected” statement is a statement about this bug, made by the vendor about their own product. Those are worth reading and they are not audits. The class of mistake here — a build flag, a preprocessor check, a fallback that was never supposed to run in production — is not exotic and is not unique to one company. A structurally identical bug hit Libbitcoin Explorer in 2023 (the “Milk Sad” vulnerability, CVE-2023-39910), where a generator was seeded with only 32 bits and wallets were actively drained.

The durable lesson is about verifiability rather than brand. Randomness you supplied yourself is randomness you can check. Randomness a device supplied is randomness you are trusting. That is why the one mitigation that held here was physical dice — and why we wrote a separate, non-urgent guide on how to verify your own seed entropy without trusting the device. The other structural answer people reach for is multi-vendor multisig, so that one vendor’s mistake is not fatal on its own: what multisig is.

Related references on this site: Bitcoin Signing Devices Reference · Bitcoin Wallet Sovereignty Matrix · Bitcoin Self-Custody: The Complete Guide.

Frequently asked questions

Primary sources

Go to these directly. Do not take our summary as a substitute for the vendor’s own words.

• Coinkite advisory (authoritative for Coldcard owners) — blog.coinkite.com/coldcard-mk3-seed-generation-warning — published 2026-07-30, updated 2026-08-01.
• Coinkite technical backgrounder — blog.coinkite.com/entropy-technical-backgrounder
• Coinkite disclosure history — coinkite.com/historical-disclosures
• Block, “Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware” — engineering.block.xyz — independent analysis, 2026-07-30.
• Wizardsardine analysis — wizardsardine.com — 2026-08-01.
• BleepingComputer, phishing campaign (Proofpoint research) — bleepingcomputer.com — 2026-08-05.
• Loss reporting — CoinDesk 2026-07-31 · CoinDesk 2026-08-02 · Crypto Times 2026-08-04 · crypto.news 2026-08-04
• Other vendors’ statements — Ledger · Trezor seed-generation analysis
• Historical analogue — Milk Sad / CVE-2023-39910

Changelog

• 2026-08-06 — First publication. Figures current to Galaxy Research’s 2026-08-04 estimates. Phishing campaign details per Proofpoint via BleepingComputer, 2026-08-05.