Coldcard firmware bug exposed private keys across five hardware wallet models

Editorial illustration for: Coldcard firmware defect exposed private keys, highlighting risks in hardware wallet seed generation

In brief

  • Coldcard firmware defect compromised seed generation in Mk2, Mk3, Mk4, Q, and Mk5 models
  • Random-number generation diverted to deterministic fallback, collapsing cryptographic entropy
  • Versions 4.0.1–4.1.9 shipped flawed firmware from 2021 until July 2024
  • BIP-39 passphrases and 50+ dice-roll seeds provided protection; updates secure new seeds only

The Firmware Flaw

Mk2 and Mk3 devices running firmware 4.0.1 through 4.1.9 produced seeds with collapsed cryptographic randomness into a small, searchable set. Mk4, Q, and Mk5 models were less severely affected, producing seeds with approximately 72 bits of entropy, well below the 128 bits specified by design. The vulnerable firmware path shipped starting in 2021 and continued until July's disclosure, a five-year window during which the flaw went undetected despite Coldcard's published source code.

The flaw's subtlety—buried in a fallback code path rarely exercised in testing—may explain why public code review did not catch it earlier. Reproducible builds confirmed that distributed binaries matched published source, yet this verification method does not catch defects in the underlying design itself.

Protection and Mitigation

Coinkite disclosed the vulnerability and released a firmware fix, though the remedy carries a critical limitation: a firmware update protects only seeds generated after the owner installs the patch. Previously generated seeds require full replacement.

Two groups of users resisted the attack. Owners who set a strong, unique BIP-39 passphrase resisted seed reconstruction because BIP-39 derives the wallet seed from the mnemonic combined with a salt containing the passphrase. Owners who generated their seed with at least 50 fair, independent, private dice rolls were excluded from this specific flaw.

The Deeper Lesson

Coldcard built its reputation on features including Bitcoin-only firmware, air-gapped signing, dual secure elements, published source code and reproducible builds. These defenses proved insufficient against a single point of failure in seed generation.

"The lesson of this incident isn't that hardware wallets are bad; it's that concentration is. When the security of your Bitcoin is reduced to a single secret, created on a single device, in a single unrepeatable moment, you've inherited every assumption that is baked into that moment." — Andrew Mannoukas, chief information security officer at Xapo Bank

Industry data has shown for years that the majority of losses come from key management and operational failures. The Coldcard incident exemplifies this pattern: the wallet hardware worked as designed, yet the seed generation process—the moment on which all subsequent security depends—contained a flaw that no amount of air-gapping or reproducible builds could prevent.

Frequently asked questions

What caused the Coldcard firmware bug?

The bug diverted the device's random-number generation from its STM32 hardware source to MicroPython's deterministic Yasmarang fallback. This collapsed cryptographic entropy, enabling attackers to reconstruct private keys from the weak seed output.

Which Coldcard models were affected?

Mk2 and Mk3 devices running firmware 4.0.1 through 4.1.9 were most severely affected, producing seeds with collapsed entropy. Mk4, Q, and Mk5 models were less severely affected but still produced seeds with only ~72 bits of entropy instead of the required 128 bits.

How can I protect my Coldcard seed?

Install the latest firmware update to protect newly generated seeds. If your seed was generated on vulnerable firmware, consider replacing it. Owners who set a strong BIP-39 passphrase or used 50+ dice rolls to generate their seed were protected from this specific attack.

Why didn't reproducible builds catch this bug?

Reproducible builds verify that the distributed binary matches published source code, confirming distribution integrity. However, they do not catch defects in the underlying design itself. The flaw was buried in a fallback code path rarely exercised in testing.