Security advisory

Coldcard seed-generation flaw — check whether your seed is affected

Active Published August 1, 2026 · affects Coldcard Q · Coldcard Mk5

A build-configuration error introduced into Coldcard firmware in March 2021 caused seed generation to silently fall back to a non-cryptographic random number generator, seeded largely from non-secret chip data. Seeds created on affected firmware carry far less randomness than the 128 bits they should — and on the worst-affected devices, little enough to be brute-forced. On 30 July 2026 an attacker did exactly that, sweeping hundreds of wallets in under an hour.

Two questions, two answers, and they are further apart than you would expect. If you own one of these devices, the section below is the one to read: your exposure depends on your seed, not on the news. If you are deciding whether to buy one, skip to why we no longer recommend it — a decision we took on August 6, 2026, and which did not change the device's rating.

The thing most people get wrong

“I updated my firmware, so I am fine.”

Updating does not repair a seed that already exists. Your exposure was decided by the firmware running at the moment the seed was first generated — not by the firmware on the device today, and not by when you bought it. Restoring a weak seed onto a brand-new device leaves it exactly as weak. The only fix for an affected seed is to generate a new one on fixed firmware and move the coins.

Is your seed affected?

This depends on which device you generated the seed on and roughly when — not on the firmware you are running today.

Highest risk

Seeds generated on a Coldcard Mk2 or Mk3 running any 4.x firmware before 4.2.0 — that is 4.0.1 through 4.1.9.

Roughly 40 bits of effective randomness instead of 128 — within reach of an offline brute-force search. This is the group the 30 July sweeps came from. Coinkite gives the Mk3 range as 4.0.1–4.1.9 and Block’s analysis puts the Mk2 and Mk3 range at 4.0.0–4.1.9; either way, anything below the 4.2.0 fix is in scope.

Also affected

Seeds generated on a Coldcard Mk4, Mk5 or Q before the fixed firmware for your release track — standard 5.6.0+ (Mk4/Mk5) or 1.5.0Q+ (Q), Edge 6.6.0X+ (Mk4/Mk5) or 6.6.0QX+ (Q).

Partial secure-element mixing left these stronger — around 72 bits by Coinkite’s reckoning — but that is still far below what a seed is supposed to have. Block’s analysis is harsher: once the fallback state and call history are pinned down, it puts the securely-distinguished search space at no more than 2³². Treat this band as serious, not as cleared.

The version-number trap

Anyone on the Edge release track.

Standard and Edge are separate tracks and Edge numbers are higher. An Edge 6.x release is not fixed merely because 6 is greater than 5.6.0 — only 6.6.0X (Mk4/Mk5) and 6.6.0QX (Q) and later carry the fix. Check your track, then your version, in that order.

Still affected even though you left

Anyone who generated a seed on an affected Coldcard and later restored it onto a different wallet — another maker’s device, a phone wallet, or software.

The weakness is in the seed itself, not in the device holding it. Restoring a weak seed somewhere else copies the weakness across. Your exposure is decided by where and when the seed was first generated, and nothing you do afterwards short of generating a new one changes that.

Out of scope, or genuinely protected

Seeds generated before the vulnerable firmware window (Mk2 and Mk3 through 3.2.2 used the hardware generator directly); seeds you created with at least 50 of your own dice rolls, rolled independently and privately and never written down anywhere digital; and TAPSIGNER, OPENDIME and SATSCARD, which run different code entirely.

On affected firmware the device hashed your dice in alongside its own weak randomness, so your rolls still count: Coinkite puts 50–98 independent private rolls at 128 bits or better from the dice alone, and 99+ at roughly 256. If you cannot remember how many you rolled, or whether the sequence was recorded, treat the seed as in scope.

Protected for now, but still migrate

Seeds behind a strong, unique BIP-39 passphrase, and multisig wallets where at least one key was generated somewhere unaffected.

These are real mitigations and they are why nothing was taken from wallets that had them — a guessed seed does not reach coins behind a phrase the attacker does not have, and one weak key out of several does not move a multisig. But the weak seed is still underneath, so the protection is only as good as the passphrase. A short, common, patterned, quoted or reused passphrase is guessable; if that describes yours, treat the funds as at risk today. Everyone in this band should migrate in their own time rather than treat it as closed.

What to do

Do not rush. A botched migration loses coins too — more people lose Bitcoin to a panicked move than to any single exploit. Work through this deliberately.
Work out whether your seed is in scope: which Coldcard model, and roughly when you first generated the seed on it. If it was generated between March 2021 and 31 July 2026 on any of the affected models, assume it is in scope until you can show otherwise.
If you used a strong unique passphrase, or generated your seed with 50+ dice rolls, or your coins sit in a multisig with a key from another maker, you have a real mitigation. It is still worth migrating in your own time.
Update to the fixed firmware first, so the device you are about to trust generates properly.
Generate a brand-new seed on the updated device — do not restore the old one — back it up, test the backup by restoring it, and only then move your coins to the new wallet.
Treat the old seed as burned afterwards. Do not reuse it anywhere, for any amount.

If you are generating a fresh seed this week

Dice are why some people were never in scope, and the migration is the one moment the extra hour costs you nothing you were not already spending. Roll your own seed with dice walks the procedure, with the current menu path for each device we rate — and, as everywhere on this site, it never asks what you rolled.

The fixed firmware

Mk2 and Mk3 — 4.2.0 or later
Mk4 and Mk5 (standard track) — 5.6.0 or later
Mk4 and Mk5 (Edge track) — 6.6.0X or later
Q (standard track) — 1.5.0Q or later
Q (Edge track) — 6.6.0QX or later

Update before you generate anything new, so the device you are about to trust is generating properly. Updating does not repair an existing seed — see above.

Where we stand

We rate the Coldcard in our cold-storage tier, and until 6 August 2026 we recommended it in the setup finder, so this lands squarely on our own recommendation and we are not going to be quiet about it. Two things are true at once, and conflating them helps nobody. A device bought today, running fixed firmware, generates a proper seed — the defect is in seeds already created, not in every Coldcard forever. But a five-year-old flaw in open-source firmware that nobody caught, in the single most security-critical function a signing device performs, is a serious mark against a maker. We said we would re-read it against our published standard rather than assume our rating still held, and that whatever we concluded would be published rather than quietly applied. That review is below — and so is what we decided afterwards, which is a different decision and went the other way.

The rating review we promised

Published 2026-08-01 — the conclusion, not a quiet edit.

The Coldcard keeps its place in our cold-storage tier.

We said we would re-read the Coldcard against our published standard rather than assume the old rating survived, and that we would publish whatever we found. Here it is, gate by gate. The short version is that nothing in our standard fails — and that the reasoning is more uncomfortable than the verdict.

Holds Your keys can never leave over the internet Holds. No Coldcard feature exports your seed to anyone, and none did here. The flaw made seeds guessable from the outside; it never shipped one anywhere. The distinction matters for the rating even though the outcome for the victims was the same.
Holds Verifiable — not a closed black box Holds, and this is the uncomfortable one. The firmware is source-available and independently reproducible, and it still is. But the defect sat in that public source for five years, and researchers were able to link the exact lines the day it surfaced. Reproducible builds did their job perfectly: they guaranteed the shipped binary faithfully matched the source, and the source had the bug in it.
Holds Bitcoin-only firmware Unaffected.
Holds A minimal, single-purpose signer Unaffected.
Holds Self-sovereign, portable recovery Unaffected — a standard BIP-39 seed, restorable anywhere.

We are not going to pretend the verdict is a clean bill of health. A five-year-old flaw in the single most security-critical function a signing device performs, in open code that anyone could read, is a serious mark against a maker — and it is a mark against the rest of us too, because "it is open, so someone would have caught it" is exactly what everybody assumed, including us. Nobody had. What verifiability actually buys you is the ability to find out afterwards, quickly and precisely, which is genuinely worth having and is not the same thing as prevention.

The obvious move would be to add a criterion about entropy: where a device gets its randomness, and whether anyone outside the company can check it. We considered it and decided against, and it is worth saying why, because the argument is not that the gap does not exist. Open, reproducible code is the highest bar available today — there is no stronger standard to hold a maker to, and the Coldcard already clears it. A rule written now would be a rule written against the specific thing that just went wrong, and the next failure will be something nobody has thought of yet. A standard that grows a new clause after every incident stops being a standard and becomes a list of past events.

What we changed is what we tell you to do about it. The people whose coins survived this were the ones who had not left the randomness entirely to the device — their own dice, a passphrase the device never saw, or a key from a different maker. So we have published a full procedure for generating a seed from your own dice rolls, on the devices we rate, checked against each maker's own current documentation. That is a thing you can act on today, and unlike a new gate it would have helped against this failure and against ones we have not imagined.

Roll your own seed with dice →

Since this was published: This review still stands and has not been rewritten. It answered one question — does the Coldcard still clear our published standard — and the answer is still yes. On 6 August 2026 we answered a different question, about whether we would tell you to buy one, and that answer changed. The section below is that decision. Read it →

We no longer recommend buying a Coldcard

Our recommendation, decided August 6, 2026 — and it is a different thing from the rating above, which has not moved.

The position, in one paragraph

The rating below is unchanged and this device still clears our published standard. We are nonetheless telling you not to buy one right now — that is our own call, on the maker rather than the hardware, and here is the whole of the reasoning.

Why

The defect is fixed and a Coldcard bought today generates a proper seed. We are not telling you otherwise, and if the hardware were the whole question we would not be writing this. What we cannot get past is everything around it. A build-configuration error sat in the seed generator — the single function a signing device exists to perform — for five years, in source anyone could read, at a company whose entire pitch is that you do not have to trust it. It was not found by an audit, or by the reproducible builds, or by us. It was found by an attacker, and the first anyone knew was money leaving.

What follows from that is not a technical claim, and we are not going to pretend it is one. It is a judgement about a company under conditions we cannot see the end of: losses still being counted, legal exposure publicly threatened, and no way for anyone outside Coinkite to know what the next twelve months hold for it. On a device whose whole job is to still be trustworthy in ten years, that uncertainty is itself the problem. We would rather point a first-time buyer somewhere with fewer open questions and be wrong about a good device than be right about the odds and wrong about someone's savings.

And there is a plainer reason underneath both, which is ours and which we would rather state than have inferred. We are an independent guide with no affiliate money and no house brand, so the only thing we have is a recommendation that means something. A recommendation you would hesitate to give a friend today is not one to leave standing on a page because the rubric technically permits it.

What is documented, and by whom

Everything in this section is somebody else's reporting and is attributed to them. It was re-read against the sources on 6 August 2026 and the numbers were still moving that day.

The mechanism

A 2021 build migration routed seed generation through a guard, MICROPY_HW_ENABLE_RNG, that checked only whether the setting was defined and not whether it was non-zero. Coinkite had defined it as zero, so the guard never fired and the firmware silently linked MicroPython's deterministic software fallback instead of the hardware generator. Both had the same function signature, so the build raised nothing. Coinkite's own advisory and Block's same-day analysis agree on this.

The losses — a range, not a number

TRM Labs puts the opening sweep at roughly 594 BTC, about $38 million, out of some 500 wallets in twenty-five minutes on 30 July. Further waves followed, and Galaxy Research's running tally is reported at around 1,816 BTC — close to $116 million — across more than 5,200 addresses. Other outlets have reported totals between $100 and $130 million and Galaxy's assessment that at least fifteen distinct attackers were involved. Every tracker publishing a figure calls it preliminary, and this advisory was originally written around the 594 BTC number, which turned out to be the first hour rather than the total.

The legal position

A class action against Coinkite has been publicly threatened and plaintiff firms are soliciting claimants. As of 6 August 2026 we are not aware of a filed case.

What we are NOT claiming

We have found no evidence that any government, regulator or law-enforcement body is investigating Coinkite, and we are not going to imply one by leaving the sentence vague. The investigating that has happened is technical — Block, Galaxy Research, TRM Labs and independent researchers — and the legal exposure is threatened rather than active. Claims circulating that an AI tool found this bug before disclosure trace back to a single anonymous post made after the flaw was already public, and we are not repeating them.

If you already own one, read this instead

Nothing above says your device is unsafe to use today. It says we would not tell someone to buy a new one. Those are different sentences and the difference matters, because the worst thing you could do with this page is panic-migrate a working setup and lose coins to a fumbled transfer — which happens far more often than exploits do.

What actually decides your exposure is the seed, not the device: when and where it was first generated, and whether you rolled your own dice or set a passphrase. That is what the bands above are for, and they are the part of this page to act on. If your seed is in scope, migrate deliberately using the steps above. If it is not, you own a capable signer and there is no emergency.

We are keeping everything that serves you. The setup walkthrough for your device stays, the dice procedures stay — including the two that only Coinkite hardware can perform — and your device keeps its cold-storage rating on the comparison table, because it earned it. When you next replace or add hardware, that is the moment to weigh what is above. Not tonight.

Check whether your seed is in scope ↑ · Setup walkthroughs, including both Coldcards →

When we would change our minds

This is a position about uncertainty, so it should end when the uncertainty does. We will re-read it when the loss accounting settles, when the legal position resolves one way or the other, and when there is a track record of the maker's process changes on the other side of it. If those land well, the recommendation comes back and we will say so as plainly as we said this. It is reviewed on a fixed schedule rather than when we happen to think of it.

The lesson worth keeping

This is the argument for a second factor that does not come from your device. A passphrase you chose, dice you rolled yourself, or a key from a different maker in a multisig — each of them meant this flaw could not reach your coins on its own. Every wallet drained on 30 July was single-signature with no passphrase. "The device generates it for you" is a single point of failure even when the device is a good one.

Sources

This is not our research. The technical findings are:

Figures were still being revised as researchers mapped the on-chain activity, so treat any single total as provisional. What is not provisional is the flaw, the affected firmware ranges, and what mitigated it.