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

Code published around this incident

Every entry states what it takes as input before it states what it does, because during a weak-key incident that is the property that decides whether a repository is safe to run.

No code. Written to be actionable.

Why the ordering is by safety

A catalogue of incident code would normally be organised by author, by finding, or by whether the code is upstream or downstream. That ordering is wrong for this incident. The question a reader arrives with is not who wrote something or how good the analysis is. It is whether running the thing can cost them their coins.

That question has a clean answer, and it does not depend on trusting the author. It depends on what the code asks for. A reproduction that fabricates its own target cannot take anything from you, because there is nothing for you to give it. A scanner that reads a firmware directory is examining a build, not a wallet. A tool that asks for a recovery phrase is dangerous whether or not its author meant harm, because the reader cannot audit what happens to the words once they are typed, and because the same request is the single most reliable marker of the checker-tool scam described at risk 3 on the scams page.

So each entry below leads with its input. Everything else, the licence, the quality of the analysis, the author's identity, is secondary to that one property.

Held in this archive

Three repositories are held here with their READMEs captured. All three were read before being described, and each was checked against the same question: what does it require the reader to supply.

DK27ss/ColdCard-38M-PoC

capture →

anonymous author · 1 Aug 2026 · No licence stated.

Accepts no wallet material

Input: Nothing. It creates its own target.

An end-to-end reproduction. It reimplements both generators, the MicroPython software fallback and the libngu mixer, fabricates its own synthetic victim wallet through the affected path, then recovers that wallet's mnemonic by searching the timer and skip space. Because the target is generated by the repository itself, the demonstration is safe by construction: it runs offline, it never needs a real wallet, and there is no input field for recovery material because there is nothing for a reader to supply.

The author is anonymous and the repository states no licence, so reuse terms are undefined. Its candidate-space and skip-model figures are the author's analysis and are not adopted here.

SamSamskies/coldcard-hack-tracker

capture →

SamSamskies · 31 Jul 2026 · MIT, with a test suite.

Accepts no wallet material

Input: Public addresses it already holds, queried against public explorers.

The published source behind the tracker dashboard this archive already tracks as a deployed page. Publishing it matters for a reason that is easy to miss: it converts an opaque third-party dashboard into something a reader can audit, so the watch set, the hop-following rules and the accounting can be checked rather than trusted. It reads public block-explorer APIs and takes no wallet material from the reader.

Its watch set is hardcoded from public reports rather than derived independently, and querying any third-party tracker discloses that query to its operator and to network intermediaries.

nobuxpt/coldcard-entropy-test

capture →

nobuxpt · 1 Aug 2026 · ISC.

Reads source trees, not wallets

Input: A firmware source tree. Not a wallet, and not a seed.

Two offline tools. A collision demonstration reproduces the reduced search space by generating seeds through a reimplementation of the affected chain and counting duplicates. A static scanner reads a firmware source directory and flags the defined-ness guard, reporting vulnerable, fixed or indeterminate. The distinction that matters is that the scanner examines source code, not a wallet: it answers a question about a build, not about your funds.

Its README states that it does not contact the Bitcoin network, derive wallet balances or scan for funds. That is the repository's own description of itself, quoted rather than independently audited here.

Why a self-generated victim matters

The proof-of-concept repository fabricates the wallet it then breaks. That design decision is what separates a demonstration from a weapon, and it is worth naming because the two would otherwise look identical from the outside. A tool that recovers a mnemonic from a search space is the same code either way. The difference is entirely in where the target comes from: generated by the repository's own script, or supplied by whoever is running it.

Already in the source register

Upstream code and the pull requests filed in response were tracked before this catalogue existed. They are listed here so that the code published around this incident can be seen in one place, with their individual capture records linked. Their inputs are not at issue: these are source files, patches and review threads rather than tools a reader runs.

Noted without recommendation

One repository has the shape this page is built to flag: its stated purpose is to accept dice input and produce wallet material, which is the input class that would make it worth examining closely. It is completely empty. There is no code, so there is nothing to examine and nothing to warn about beyond the fact that a stated purpose is not a published implementation. It is recorded so that its later appearance with content is a change rather than a discovery, and it is not linked, because linking an empty repository whose contents are unknown would be a recommendation this archive cannot support.

Separately, forks of the proof-of-concept repositories were compared against their upstreams. As of 2 August 2026 none had diverged. A fork that adds an input field for recovery material to an otherwise safe reproduction is the realistic way this class of code turns hostile, so the comparison is recorded, along with its date, rather than left implicit.

The negative finding, and its limits

As of 2 August 2026, no malicious seed-checker was found in public code indexes. That is the finding most worth stating plainly, and the one most easily misread.

It is a time-bounded observation, not an all-clear. It says that a search of public indexes on one date did not surface such a tool. It does not say that none exists, and it says nothing at all about tools hosted outside public code indexes, which is where a working phishing checker would rationally live: on a domain, behind an advertisement, in a message. The scams page ranks that vector third precisely because its absence from code hosting is weak evidence about its presence in the world.

The test that does not require trusting anyone

Whether this incident affects you is answerable from the firmware version installed when the seed was generated and how that seed was created. Neither fact is secret. Any tool, repository or page that asks for a recovery phrase, a private key or an extended private key in order to answer that question is asking for material that cannot contribute to the answer, and is hostile by construction regardless of what its author intended. The reasoning is set out under risk 3 on the scams page, and the safe path through seed handling is on seed-word safety.

Next: Scams exploiting this incident why a checker tool that asks for recovery material is hostile whatever its author intended

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.