COLDCARD vulnerability what happened, and what to do
Informational only, and this site never asks for your recovery words. details

Informational only. This is independent analysis and an evidence-backed explainer, not financial, security or legal advice, and not a substitute for professional advice about your own situation. It is not affiliated with, endorsed by, or speaking for Coinkite, Block, or any other party named here. Published estimates are attributed, and differing scenarios are kept separate with their assumptions. Act on your own judgement. Editorial standards and corrections.

Do not disclose recovery material to a website, form, message or support account. This site never asks for it. Deliberate recovery on independently verified offline equipment is a separate operation. Seed-word safety.

Plain language Updated 2 Aug 2026

Firmware timeline

The releases and source commits that bound the affected firmware ranges, with dates from the vendor's history files.

No code. Written to be actionable.

Exposure is bounded by the firmware that was running when the seed was generated, not by the device in front of you today. A COLDCARD updated to a hotfix release can still hold a seed created on an affected build, and a device left on an affected build matters only if a seed was generated on it. The first table gives the affected ranges by model; the second identifies the individual releases and commits that mark each boundary. If you need to act on this rather than check it, start with the risk assessment, and see checking and updating your device below for what a firmware update does and does not fix.

Firmware generation status by model and release range
ModelFirmware at generation StatusCandidate-space noteNotes
Mk1≤ v3.0.6final Mk1 build, 19 Dec 2019 Not affectednominal 128 or 256 bits Predates the libngu migration.
Mk2 / Mk3≤ v3.2.2up to 14 Jan 2021 Not affectednominal 128 or 256 bits Seed generation used ckcc.rng_bytes(), which reaches the STM32 TRNG directly. The next published release, v4.0.0, is the first one containing the affected path.
Mk2v4.0.0 to v4.1.917 Mar 2021 to 26 Jun 2023Coinkite states v4.0.1 to v4.1.9 AffectedBlock: 2^0 fixed state;
<2^40.7 loose ceiling
Generation moved to ngu.random, and this hardware has no secure-element reseed at all. Mk2 never received a v5.x release. Coinkite's advisory names this model directly, stating that the issue "is present on Mk2 and Mk3 firmware versions 4.0.1 through 4.1.9 inclusive"; that wording dates from its revision of 1 August 2026 at 18:35 UTC, before which the advisory named only the Mk3. Coinkite's advisory starts this range at v4.0.1, while this site includes v4.0.0 on the release-commit and signed-release evidence, which does not itself establish how widely that build was installed before v4.0.1 arrived twelve days later. Other models use different assumptions.
Mk3v4.0.0 to v4.1.917 Mar 2021 to 26 Jun 2023Coinkite states v4.0.1 to v4.1.9 AffectedBlock: 2^0 fixed state;
<2^40.7 loose ceiling
Coinkite described the entropy as approximately 40 bits; LLFOURN published a separate ~2^40.3 model. Firmware v4.1.9 remained the last published Mk3 release until v4.2.0 was published on 31 July 2026. Coinkite's advisory starts this range at v4.0.1, while this site includes v4.0.0 on the release-commit and signed-release evidence, which does not itself establish how widely that build was installed before v4.0.1 arrived twelve days later. The model register states each assumption.
Mk4v5.0.0 to v5.5.114 Mar 2022 to 1 Jul 2026 Affected≤2^32 conditional scenario;
<2^73.3 loose ceiling
On the normal successful boot path, rng_seeding() derives a value from secure-element output but carries at most 32 bits into libngu. Coinkite, LLFOURN and Talip publish different broader models.
Mk5v5.5.0 to v5.5.15 Mar to 1 Jul 2026 Affected≤2^32 conditional scenario;
<2^73.3 loose ceiling
The first repository release explicitly supporting Mk5 is v5.5.0. Both published pre-hotfix Mk5 releases are affected. Other models use different assumptions.
Qv0.0.3Q to v1.4.1Q8 Feb 2024 to 1 Jul 2026 Affected≤2^32 conditional scenario;
<2^73.3 loose ceiling
All Q builds recorded in the published release history before v1.5.0Q are affected, including the v1.0.0Q production release of 10 Mar 2024. Other models use different assumptions.
Mk2 / Mk3v4.2.0official Mk3 X update: 31 Jul 2026, 13:43 UTC Published fixnominal 128 or 256 bits in the reviewed source The release history describes a hotfix that corrects the entropy bug and allows new seed generation. Coinkite's advisory lists the fixed release as "Mk2/Mk3: version 4.2.0 or later" and describes "Fixed Mk2/Mk3 firmware version 4.2.0" as released. Before the advisory's revision of 1 August 2026 at 18:35 UTC it named only the Mk3, and the vendor downloads-page listing of 4.2.0 for "COLDCARD Mk3 and Mk2" was the only vendor evidence covering the Mk2. The source contains the hardware-RNG fix; this archive has not reproduced the vendor build, installed it on either model or independently inspected the signed binary.
Mk4 / Mk5v5.6.0signed release: 31 Jul 2026, 05:18 UTC Published fixnominal 128 or 256 bits in the reviewed source The signed-release record precedes source release commit 3238f6f at 05:19 UTC. That commit contains the source-level fix. The advisory separately names Edge v6.6.0X; neither published binary has been independently checked here.
Qv1.5.0Qsigned release: 31 Jul 2026, 05:17 UTC Published fixnominal 128 or 256 bits in the reviewed source The signed-release record precedes source release commit 3238f6f at 05:19 UTC. That commit contains the source-level fix. The advisory separately names Edge v6.6.0QX; neither published binary has been independently checked here.
OPENDIMEV3.0 r.Afirmware 2.2.0 One-device test reporteduser entropy incorporation reported for one unit Foundation Devices co-founder and CEO Zach Herbert reports reconstructing the final private key from the exact user-provided test vector, USB serial and revealed nonce. Foundation sells competing hardware-wallet products. The test covers one unit, does not assess internal-nonce quality and was not independently reproduced here.
TAPSIGNERAll Vendor-reportednot independently assessed here Coinkite reports that TAPSIGNER is not affected because it uses a different codebase. Rob Hamilton notes that its closed source prevents first-hand verification and reports only preliminary evidence that it does not use the affected libngu path.
SATSCARDAll Vendor-reportednot independently assessed here Coinkite reports that SATSCARD is not affected because it uses a different codebase. This archive has not independently reviewed that codebase.

For the named 31 July hotfixes, the source-level change is verified. The signed release files are vendor-published, but this archive has not reproduced the builds or independently inspected the binaries.

Release boundary record

Purchase date does not determine exposure; the published build in use at generation does. The selected releases below identify the relevant boundaries from the per-model history files.

Selected firmware and source release boundaries
VersionReleasedLineStatusWhy it matters
3.2.214 Jan 2021Mk2 / Mk3Last pre-regression releaseSeeds generated on this or an earlier release used ckcc.rng_bytes() and are not affected by this generator substitution.
b18723dddb6d751c39978e4364b56b2414f68b47verified in the firmware repository1 Mar 2021commitMigration commitNot a release. This commit moved wallet generation from ckcc.rng_bytes() to ngu.random.bytes(), combining with the pre-existing guard defect to create the affected path.
4.0.017 Mar 2021Mk2 / Mk3First affectedCoinkite starts at v4.0.1Release commit 910e306e79f7eb6e99d16e253075de42f055124c contains the affected path, and the signed-release record lists the 17 Mar 2021 DFU image. Coinkite's advisory starts this range at v4.0.1, while this site includes v4.0.0 on the release-commit and signed-release evidence, which does not itself establish how widely that build was installed before v4.0.1 arrived twelve days later.
5.0.014 Mar 2022Mk4AffectedFirst Mk4 production firmware and the first to call rng_seeding() at boot, which is the 32-bit reseed.
4.1.926 Jun 2023Mk2 / Mk3AffectedThe last Mk3 firmware for three years, and affected. Superseded by 4.2.0 on 31 Jul 2026.
0.0.3Q8 Feb 2024QAffectedEarliest public Q build. Production 1.0.0Q follows 10 Mar 2024.
5.5.0 / 1.4.0Q5 Mar 2026Mk4 / Mk5 / QAffectedThe build the Mk5 shipped on when that hardware launched five days later.
5.5.1 / 1.4.1Q1 Jul 2026Mk4 / Mk5 / QLast affected releaseThe last published affected release before disclosure.
4.2.031 Jul 202613:43 UTC official Mk3 updateMk2 / Mk3Published fixThe release history says this corrects the entropy bug and allows new seed generation. Coinkite's advisory names it for both models as "Mk2/Mk3: version 4.2.0 or later", wording it adopted on 1 August 2026 at 18:35 UTC, and the vendor downloads page lists it for Mk2 and Mk3. The reviewed source contains the fix, while installation on either model and the signed binary remain unexamined by this project.
1.5.0Q31 Jul 202605:17 UTC, signed releaseQPublished fixThe signed-release record identifies this Q hotfix. Source release commit 3238f6f follows at 05:19 UTC and contains the source-level fix. No local build or disassembly of the shipped image was attempted.
5.6.031 Jul 202605:18 UTC, signed releaseMk4 / Mk5Published fixThe signed-release record identifies this Mk4/Mk5 hotfix. Source release commit 3238f6f follows at 05:19 UTC and contains the source-level fix. The shipped image was not reproduced against that source here.
3238f6fd9977eed786012d0034a04d888c3263bbverified in the firmware repository31 Jul 202605:19 UTCMk4 / Mk5 / Q sourceSource fix verifiedThe release commit states that it will generate entropy correctly and contains the source-level fix. This verifies the source change, not the contents of the earlier signed release files.
6.6.0X / 6.6.0QX31 Jul 202616:54 UTC official X updateMk4 / Mk5 / Q EdgeVendor-reported fixCoinkite names these exact Edge releases in its advisory and official update. Their binaries fall outside what this archive has examined.
5 yr 4 mo
Mk3 affected interval
v4.0.0 on 17 Mar 2021 to the Mk2/Mk3 fix the vendor names on 31 Jul 2026.
4 yr 4 mo
Mk4 exposure
v5.0.0 on 14 Mar 2022 to the Mk4 fix on 31 Jul 2026, covering every release through v5.5.1.
2 yr 5 mo
Q exposure
v0.0.3Q on 8 Feb 2024 to the Q fix on 31 Jul 2026, covering every recorded Q build through v1.4.1Q.
3 yr 1 mo
Mk3 release interval
Time between v4.1.9 and the 4.2.0 hotfix.
The vendor advisory starts at v4.0.1; source evidence includes v4.0.0 Both the Mk3 advisory and the technical backgrounder, in the versions held here as of 2 August 2026, give the affected range as "4.0.1 (March 2021) through 4.x". Bitcoin Optech repeated it, citing the advisory. Neither boundary looks like a typographical slip: the advisory states 4.0.1 twice, and this site states 4.0.0 from the repository record. Coinkite has already revised this range once, from a first advisory state that ran the issue "through firmware version 5.0.3".

The release history in the vendor's own repository puts 4.0.0 on 17 March 2021 and describes it as "Major internal changes... all crypto and BIP39 related code replaced", which is the migration that introduced the bug. 4.0.1 did not arrive until 29 March, and its changelog entry is about something else entirely: "Fixes security issue in v4.0.0."

The 17 March release commit contains random.bytes(32), the defined-zero board macro, the vulnerable libngu revision and the MicroPython fallback revision. The signed-release record also lists the 4.0.0 image. Block's range starts at 4.0.0.

The evidence therefore supports classifying a seed generated on Mk2 or Mk3 v4.0.0 as affected, notwithstanding the narrower Coinkite wording. What it does not establish is distribution: the record shows that 4.0.0 was built and signed, not how many devices ran it during the twelve days before 4.0.1 superseded it.

One piece of outside evidence bears on the same boundary from a different direction. Chain analysis published by Galaxy Research on 1 August 2026 reports that no coin drained in its first three sweep waves was created before roughly block 674,951 on 17 March 2021, which is the v4.0.0 release date rather than the 29 March v4.0.1 date, so it corroborates a March 2021 onset without settling which of the two releases marks the boundary. Galaxy's wording is "The vulnerable Coldcard firmware shipped on March 17, 2021 around block 674,951. Not one of the coins we have identified in Waves 1-3 taken was created before that block."

Three limits belong with that. The block height is Galaxy's own approximation. The finding is about when coins were first received rather than about which firmware generated any particular seed, and Galaxy separately records that it has "not utilized compute to test whether the addresses we have identified as possible victims were indeed generated with low entropy". And twelve days is too narrow an interval for coin creation dates to separate 4.0.0 from 4.0.1, so an absence of earlier victim coins is consistent with the 4.0.0 boundary rather than decisive between the two. The classification above rests on the release commit, the pinned libngu revision, the defined-but-zero board macro and the signed 4.0.0 image; this is corroboration of a March 2021 onset set beside that evidence, not a replacement for it.
A correction to the original advisory The 30 July Mk3 advisory described the affected range as running "through version 5.0.3, the final release that supported Mk3". That wording survives only in the 01:56 UTC state of 31 July recovered from the Internet Archive; this project's own capture of the advisory began on 1 August, by which point the sentence was gone. History-Mk3.md ends at v4.1.9 and contains no 5.x release, while v5.0.3 appears in the Mk4 history. Block's stated range of v4.0.0 to v4.1.9 matches the repository record. This does not change which published Mk3 builds are classified as affected, but v4.1.9 is the highest Mk3 version in that history.

Checking and updating your device

Two of the questions this page is used to answer are practical: which build is on the device now, and where a replacement build should come from. The archive can support both from held captures, within limits stated here.

Reading the installed version. The COLDCARD shows its firmware version in the device's own settings and upgrade menus. The published release history records a "show firmware version" display being added to the Advanced/Tools menu, and lists an Upgrade Firmware menu item on that same branch. Menu labels differ between models and between firmware generations, so treat that path as the place to look rather than an exact route for every device. This archive holds no capture of a per-model menu walkthrough, and no screenshots of any device.

Where firmware should come from. Coinkite publishes builds on its own downloads page, and this archive holds a capture of that page. At the 1 August 2026 capture it listed 4.2.0 for Mk3 and Mk2, 5.6.0 for Mk4 and Mk5, 1.5.0Q for Q, and 6.6.0X and 6.6.0QX for the Edge line. Take the image from the vendor's own channel rather than a mirror, a link in a message, or a search result. The vendor's documentation describes the upgrade itself as copying the firmware file onto a MicroSD card.

Verification, stated narrowly. Confirm the release through an independently verified vendor channel and check its signature or hash using the vendor's documented process. What this archive can point at directly is narrower: the release history documents on-device verification of detached Bitcoin signature files under Advanced/Tools, which is a check for files the device exports rather than a published procedure for the firmware image. No captured source held here sets out a step-by-step firmware-signature check, so this page does not print one.

An update does not repair a seed Installing a hotfix changes what the device will generate next. It does not alter a seed that already exists. The 31 July advisory state put it directly: "An update cannot repair a seed that was already generated by affected firmware." A device on 4.2.0, 5.6.0 or 1.5.0Q that is still holding funds under a seed generated on an affected build is in exactly the position it was in before the update, and the risk assessment is the next step rather than the upgrade screen.

Evidence and calculations are scoped beside the claims they support. Device-state attack-cost scenarios are compared in what an attack costs, with each source's assumptions written out. Where sources disagree, their scenarios are kept separate. If something here is wrong, say so.