In the world of cryptocurrency, there’s a rule everyone learns early: trust the math, and trust your hardware wallet. We lock our savings behind secure elements, true random number generators, and air-gapped devices. But what happens when a single line of code quietly undermines that entire foundation?
Coinkite recently published a technical backgrounder detailing a severe vulnerability in how their Coldcard devices generated wallet seeds. Here’s exactly what happened, why it matters, and why it’s worth taking seriously even if you don’t own a Coldcard yourself.
Mathematics doesn’t care about the brand name on your device. Let’s break down the incident.
The Mechanics of the Failure
To create a secure 12-word or 24-word recovery phrase, a hardware wallet needs entropy, meaning genuinely unpredictable randomness. A standard 12-word seed contains 128 bits of entropy. Guessing a 128-bit secret before the sun burns out is computationally impossible.
Coldcard devices ship with a True Hardware Random Number Generator built specifically for this task. In March 2021, a firmware update broke that process without anyone noticing.
During a code migration, a single configuration macro, MICROPY_HW_ENABLE_RNG, was mistakenly set to zero. Because of an incorrect check in the supporting library, the device silently stopped using the hardware TRNG and fell back to a weak, software-based pseudorandom number generator instead.
That software PRNG was seeded mainly from non-secret, easily modeled device state, things like the chip’s unique serial number and internal clock timing.
On affected Mk3 devices, effective entropy dropped to an estimated ~40 bits under realistic attack assumptions. Later models (Mk4, Mk5, Q) mixed in some additional entropy from secure elements and fared somewhat better, but still landed around ~72 bits, short of the intended target.
Cryptographic hashing can’t manufacture entropy that isn’t already present in its input. If the ingredients are predictable, the output is predictable too, and that’s the root cause of the exploit.
This is a different failure mode entirely from phishing attacks targeting hardware wallets or pre-filled seed phrase scams. No user error was involved here, the device itself generated a weak seed.

Why This Matters
The software fallback didn’t draw on unpredictable real-world physics to generate a seed. It used easily guessable, non-secret device state, a chip’s serial number and its internal clock.
If a sophisticated attacker knows a device’s serial number and a rough timestamp of when the seed was generated, that wallet is essentially standing with the front door wide open. Forty bits of entropy isn’t a theoretical weakness, it’s squarely within the range modern computing can brute-force.

How the Attack Actually Happened
What makes this incident remarkable is that the attacker never had to compromise any hardware wallet directly.
Instead, they exploited the dramatically reduced search space created by the faulty entropy process. By understanding exactly how the vulnerable firmware generated seeds, they could recreate that process offline and generate candidate seed phrases at scale.
Rather than attempting to brute-force the full Bitcoin keyspace, an impossible task, the attacker only needed to search the much smaller space of seeds that vulnerable Coldcard devices could realistically produce. On affected Mk3 devices, that meant searching roughly 240 possibilities instead of the intended 2128, a reduction of nearly 88 bits of security.
From there, the attack became a large-scale matching exercise: generate millions of candidate seeds using the flawed entropy model, derive the corresponding Bitcoin addresses, compare those against the public blockchain, identify addresses holding meaningful balances, then recover the matching private keys and sweep the funds.
Because every Bitcoin address and balance is publicly visible, the blockchain itself became the attacker’s lookup table. Once a generated address matched one holding bitcoin, the wallet’s secret was effectively recovered.
Evidence suggests the attacker specifically targeted high-value wallets, ignoring small balances to maximize return while minimizing transaction volume. The initial wave swept several hundred BTC from roughly 500 wallets in about 10 minutes, in a coordinated operation lasting around 41 minutes.

This wasn’t a traditional attack involving malware, phishing, or physical device compromise. It was a purely cryptographic attack, made possible because the wallet seeds were never as random as they were supposed to be. Once the attacker found the weakness, every vulnerable wallet became a target, even ones that had sat untouched offline for years.
The Scale of the Exploit
Perhaps the most alarming part of this incident is that it wasn’t an isolated theft. It became an ongoing, automated campaign.
Blockchain analysis shows the attacker has continued identifying and draining vulnerable wallets generated with the flawed firmware, unfolding in multiple coordinated waves as newly discovered vulnerable wallets are found.

At the time of writing, thousands of Bitcoin addresses have been drained across multiple attack waves, with the total stolen climbing into the tens of millions of dollars and still rising. Nearly all of the stolen bitcoin remains under the attacker’s control, consolidated into a small number of wallets and not meaningfully laundered or spent yet.
That the attacker has held onto nearly everything stolen so far suggests this campaign isn’t finished. As additional vulnerable seeds are identified, or as dormant wallets created years ago suddenly receive new deposits, they remain live targets.
For readers following the investigation, the exploit is being tracked in real time at coldcardwatch.com, which maintains live statistics on affected wallets, BTC stolen, attack waves, and the attacker’s current holdings.
What You Need to Do
If you generated a wallet seed on a Coldcard device using firmware released after March 2021, treat that seed as potentially compromised. Read Coinkite’s official disclosure, update your device’s firmware to a patched version, and strongly consider generating a new, truly random seed and migrating your funds. Seeds generated via dice rolls, rather than on-device, are not affected by this issue.
Key Takeaways for Developers
Never silence a compiler error or ship a quick fix you don’t fully understand just to make the build pass. In the Coldcard case, a developer hit a conflicting-symbol error and simply set MICROPY_HW_ENABLE_RNG to zero. The build succeeded, for the wrong reason. That single change disabled the hardware RNG across the board and silently substituted a weak software generator into every new wallet from that point forward. The commit message was just “runs.”
One poorly understood shortcut can cascade into catastrophic, real-world damage. Stop and understand a change completely before shipping it. Whatever deadline pressure prompted the shortcut isn’t worth the devastation a butterfly-effect bug like this one can cause.
Key Takeaways for Repository Owners
Coldcard’s GitHub repository had no branch protection on its master branch. Anyone with write or maintainer access could push directly, no required pull request, no required reviews, no CODEOWNERS file, no status checks.
GitHub already offers the tools to prevent this: branch protection rules requiring a pull request and approvals before merging, CODEOWNERS for automatic reviewer assignment, required status checks and CI, and the ability to restrict who can push to main. None of these are exotic. All of them would have caught this change before it shipped.
The Takeaway
This isn’t meant to induce panic, it’s meant to instill a healthy sense of vigilance. In cryptography, silent failures are the most dangerous kind. The device looked fine, it acted fine, and it handed out a completely normal-looking 12-word or 24-word seed phrase. Underneath, the foundational math was compromised the entire time.
Randomness isn’t something you can verify by looking at the output. It has to be engineered correctly from the start, and checked by more than one set of eyes before it ships.
Worried about whether your organization’s crypto infrastructure or wallet security posture has blind spots like this one?
See how PhishFort helps crypto and Web3 businesses detect threats before they cost you →
Update: Attackers moved fast on this one, see how they weaponized it in a phishing campaign days later→



