The Coldcard Firmware Flaw: What Happened, Who’s Affected, and How to Respond

Coldcard is a Bitcoin-only hardware wallet made by Coinkite, a Toronto-based company that has sold Coldcard devices since 2017. A hardware wallet is a small, purpose-built electronic device that generates and stores the cryptographic keys controlling a cryptocurrency holder’s funds, and signs transactions, without ever exposing those keys to an internet-connected computer or phone. The core idea is straightforward: an ordinary computer is a large, complex, frequently-compromised piece of software running an operating system with millions of lines of code and a broad attack surface; a hardware wallet is a small, narrowly-scoped device that does one job and, ideally, can be verified to do only that job.

Firmware is the software permanently or semi-permanently programmed into a hardware device to control its basic operation — the layer between the physical chips and any higher-level application logic. On a hardware wallet, firmware is where the most security-critical operations live: generating randomness, deriving keys, displaying transaction details for the user to verify, and signing. A flaw in firmware is different from a flaw in a phone app: it typically requires an intentional update process to fix, it often affects every unit that ran the flawed version regardless of when the flaw is found, and — as this incident shows — it can lie completely dormant, generating quietly-broken output, for years before anyone notices.

What was reportedly discovered: in late July 2026, security researchers and Coinkite itself confirmed that a firmware defect, introduced in March 2021, had caused affected Coldcard devices to generate wallet seed phrases using a predictable software algorithm instead of the device’s dedicated hardware random-number generator. Because a Bitcoin private key is only as secure as the randomness used to create it, this meant that seeds generated on affected firmware could, in principle, be recreated by an attacker who knew (or could narrow down) the same inputs the software fallback used — without ever touching the physical device.

Why firmware flaws matter more on a hardware wallet than almost anywhere else: the entire value proposition of the device is that a user does not have to trust their operating system, their browser, or their network connection — only the device itself, and the firmware running on it. When that narrower trust boundary fails, the attack surface a user believed they had eliminated by going “cold” reappears, except now it is harder to detect precisely because the device is offline and the flawed output looks, to the user, identical to correct output. There is no error message. The seed phrase displays normally. The device behaves exactly as designed — it is simply not doing the one thing it exists to do.

Vulnerability versus exploit — the distinction this article holds to throughout: a vulnerability is a weakness in a system that could, under the right conditions, be used to cause harm. An exploit is the actual, demonstrated use of that weakness to cause harm. Plenty of vulnerabilities are found, patched and never meaningfully exploited; the gap between discovery and any real-world impact is exactly what responsible disclosure processes exist to protect. This incident is unusual, and more serious than a typical disclosure story, precisely because the order was reversed: the vulnerability was not found by a researcher and quietly reported — it was found because it was already being actively exploited, on-chain, in public, by the time anyone flagged it.

Why responsible disclosure is important, and why this case is a case study in what happens without it: the standard model, when a researcher finds a security flaw, is to report it privately to the vendor, give the vendor a defined window to build and ship a fix, and only then publish full technical details — so users have a patch available before attackers have a roadmap. That model depends on the researcher finding the bug first. Here, the timeline ran the other way: attackers appear to have found (or independently rediscovered) the flaw before any researcher reported it, and Coinkite learned about it from watching funds move rather than from a private disclosure email. The rest of this guide traces exactly how that played out, hour by hour, over the last week of July 2026.

A Coldcard is built around a general-purpose microcontroller (an STM32 chip, in every model to date) that runs the device’s MicroPython-based firmware, paired — from the Mk4 onward — with a dual secure-element setup used for additional key storage and randomness reinforcement. The device has no wireless radio of any kind: no Wi-Fi, no Bluetooth, no cellular modem. Its only connections to the outside world are a USB port (used mainly for power and, on some workflows, direct communication with trusted software), a microSD card slot, and — on the Q model — a built-in QR code scanner and keyboard.

When a user generates a new wallet, the device is supposed to gather genuine physical randomness from a hardware random-number generator built into the STM32 chip — a component specifically designed to produce output that is unpredictable even to someone who knows the device’s exact make, model and firmware version. That raw randomness becomes the entropy behind a BIP-39 seed phrase, which in turn deterministically derives every private key and address the wallet will ever use. The device displays the resulting words on its own screen, never transmitting them anywhere, so a user can write them down without the phrase ever touching a camera, a network, or another piece of software.

For everyday transactions, Coldcard is designed to be used air-gapped: a companion watch-only wallet on a computer or phone builds an unsigned transaction, exports it as a PSBT file to a microSD card (or, on the Q, a QR code), the Coldcard reads that file, displays the transaction details on its own screen for the user to verify, signs it internally using keys that never leave the device, and exports the signed result back the same way — at no point does a network-connected device see the private keys themselves.

Every official Coldcard firmware release is cryptographically signed by Coinkite before publication. The device’s bootloader — the small program that runs first, before the main firmware — checks that signature before allowing new firmware to run, so that installing a modified or unofficial build should fail the check and refuse to boot. This is the “firmware trust chain”: the bootloader trusts only firmware signed by Coinkite’s key, and the user, in turn, trusts that Coinkite’s signing process is itself secure.

It’s worth being precise about exactly what this protects, because this incident is a clean illustration of its limits. Signature verification answers one question: is this genuinely Coinkite’s own, unmodified firmware? It does not, and cannot, answer a different question: is this firmware correctly written? The firmware that shipped the RNG flaw was authentic, signed, and unmodified — it passed every signature check a device could run. The defect was a logic error inside code that was, in every verifiable sense, exactly what Coinkite intended to ship.

Physical attacks require an attacker to have the device itself in hand — chip-level extraction, fault injection, or side-channel analysis performed directly against the hardware. These are typically the highest-effort, highest-skill attacks, and the ones secure elements and tamper-resistant design are specifically built to raise the cost of.

Remote attacks target the device over a network connection or through compromised software on a connected computer. Because a properly air-gapped hardware wallet has no wireless radio and never exposes private keys to a connected machine, classic remote attacks (malware reading a key directly, for instance) are largely designed out of the picture for devices like Coldcard when used as intended.

Supply-chain risks involve tampering before a device ever reaches its owner — a compromised unit intercepted in shipping, or a malicious modification introduced during manufacturing. Coldcard’s tamper-evident packaging and its “trust-minimized” setup flow (encouraging users to update firmware and verify their device’s authenticity themselves rather than trusting the box) are aimed at this category specifically.

User mistakes — typing a seed phrase into a phone, photographing a backup, falling for a phishing site impersonating a wallet vendor, reusing a seed across an insecure app — remain, by a wide margin, the most common real-world cause of self-custody losses, independent of any single device’s firmware quality.

The Coldcard RNG flaw does not fit neatly into any one of these four buckets, which is part of what makes it notable. It required no physical access to any individual victim’s device, no malware on any victim’s computer, and no supply-chain tampering — an attacker who worked out the flawed randomness generation could, in principle, regenerate a plausible set of candidate private keys entirely offline and simply watch the blockchain for funds to appear at the resulting addresses. It is closest, in effect, to a cryptographic design flaw: a weakness in the mathematics and logic underlying key generation itself, rather than in any single layer of physical or network security.

A Partially Signed Bitcoin Transaction (PSBT) is the standard file format that makes air-gapped signing practical. A watch-only wallet — software that can see balances and build transactions but holds no private keys — assembles an unsigned transaction and saves it as a PSBT. That file moves to the Coldcard via microSD card or QR code, never over a network connection. The Coldcard parses the PSBT, displays the destination address and amount on its own screen so the user can independently verify what they’re about to sign, signs the transaction using keys that never leave the device, and writes the now-signed PSBT back to the same medium. The watch-only wallet reads the signed file and broadcasts it to the Bitcoin network. The Coldcard itself never touches the internet at any point in this sequence.

A multisig wallet requires signatures from a defined subset of independently held keys — commonly written as “M-of-N,” such as 2-of-3 — to authorize a transaction. The security benefit is straightforward: a single compromised key, device, or seed phrase is not, on its own, sufficient to move funds. An attacker needs to compromise the threshold number of independent keys, ideally held on different devices, in different locations, sometimes from different vendors entirely.

That last detail matters directly for this incident. Diversifying where keys are held only helps if it also diversifies the method used to generate them. A 2-of-3 multisig wallet where all three keys were generated on Coldcard devices during the vulnerable window offers meaningfully less protection against this specific flaw than the same 2-of-3 structure would suggest at a glance — because the same underlying weakness could, in principle, apply to more than one of the three keys simultaneously. Multisig protects best against this kind of flaw when cosigner keys are generated on genuinely different hardware and firmware, ideally from different manufacturers.

A seed phrase backup is only as good as its resistance to the two failure modes that matter: someone unauthorized finding it, and everyone authorized losing access to it (fire, flood, simple misplacement). Paper is fragile and flammable. Engraved or stamped metal plates resist fire, water and physical decay far better, which is why they are widely recommended for anything beyond trivial amounts. Geographic distribution of backup copies — not all in one location — protects against a single localized disaster, at the cost of more moving pieces to secure and track.

A vulnerability is a condition that could lead to harm. An exploit is proof that it did, or a demonstrated method to make it. The overwhelming majority of security vulnerabilities disclosed every year in every industry are patched before meaningful exploitation occurs — found by researchers, reported privately, fixed, and published only as a historical footnote. That is, by a wide margin, the more common and less alarming outcome.

This incident sits at the far end of the spectrum specifically because that gap never existed here in a form that protected users. The vulnerability was present, live, in shipping firmware, from March 2021. The exploit — funds actually, provably stolen — began July 30, 2026. For more than five years, the vulnerability existed without (as far as any public record shows) being exploited; then, within a period of days, it went from undiscovered to the subject of a $116 million theft. Understanding which state a given security story is in — disclosed-but-unexploited, or actively-exploited — is the single most important piece of context for judging how urgently to act on it.

The standard responsible-disclosure lifecycle exists to give a vendor time to build a fix before attackers have a public roadmap to the problem. It typically runs: a researcher discovers a flaw privately, reports it directly to the vendor under a coordinated timeline, the vendor investigates and develops a patch, and technical details are published only once a fix is available (or a pre-agreed deadline passes). Done well, users never experience a window where the vulnerability is both public and unpatched.

This incident’s actual sequence ran differently, and this guide treats that divergence as a fact worth stating plainly rather than glossing over: the earliest public evidence of the flaw was Bitcoin holders’ funds moving without their authorization, not a private research report. Independent technical analysis (Block’s, Wizardsardine’s) followed the public exploitation rather than preceding it. Whether the attackers themselves independently discovered the same root-cause bug, rediscovered it via automated code analysis, or obtained it some other way, is not established in any source reviewed for this guide — and this article does not speculate further on that point beyond noting Coinkite’s own CEO raised, without confirming, the possibility that AI-assisted code review played a role.

The three most established names in Bitcoin and multi-asset hardware wallets — Coldcard, Trezor and Ledger — have historically made different tradeoffs on the same handful of design questions: how open is the firmware, is a certified secure element used, and how is air-gapped operation supported. None of this comparison should be read as a claim that Trezor or Ledger devices are affected by the Coldcard-specific RNG bug detailed in this guide — no source reviewed for this article ties this incident to any other manufacturer.