COLDCARD Wallets Were Drained Without Users Exposing Their Seed Phrases—Here’s How

By Cryptosafekit | CryptoSafeKit | 5 hours ago


b6b0456c80ee0c0e5d499f32a24c5a5a884626ae814c4a8d8d58d1bec16d0a63.png

The COLDCARD entropy bug shows why self-custody security begins when your recovery phrase is created—not when your device goes offline

Imagine doing almost everything crypto security guides tell you to do.

You buy a hardware wallet.

You generate the recovery phrase privately.

You write the words on paper and never photograph them.

You never type the phrase into a website, phone, browser extension, or cloud document.

Your device remains offline for years.

Then the funds disappear.

Not because someone found the backup.

Not because you approved a malicious transaction.

Not because the hardware wallet was physically stolen.

The weakness may have existed before the first deposit—inside the process that generated the wallet’s secret.

That is what makes the recent COLDCARD security incident so uncomfortable.

What Happened?

Coinkite, the company behind COLDCARD, disclosed a random-number-generation integration error affecting seeds created by certain firmware versions.

A wallet recovery phrase must be generated from strong and unpredictable randomness. In simple terms, the possible secret should come from such an enormous space that guessing it remains computationally unrealistic.

According to Block’s Bitcoin Engineering and Security teams, affected COLDCARD firmware could reach a deterministic software fallback instead of using the intended hardware random-number generator.

The impact differed by device generation:

  • Certain Mk2 and Mk3 firmware paths lacked the intended cryptographic entropy during wallet creation.
  • Later Mk4, Q, and Mk5 devices added secure-element entropy, but the effective secure contribution was still substantially below the intended target.
  • Exposure depended on the firmware used when the seed was generated—not simply the device’s purchase date or current firmware version.

Block stated that active exploitation appeared to be underway, while also noting that its analysis reflected the researchers’ current understanding and was not a completed end-to-end empirical exploit study.

Coinkite subsequently confirmed affected firmware ranges and released corrected firmware for the relevant models. Its advisory says some later-model seeds had approximately 72 bits of entropy rather than the expected 128 bits.

Why Offline Keys Were Not Enough

A hardware wallet is often described as a device that keeps private keys offline.

That description is accurate, but incomplete.

A secret can remain completely offline and still be vulnerable when it was generated from an insufficiently unpredictable source.

The attacker does not necessarily need to:

  • Touch the device
  • Infect the owner’s computer
  • Photograph the recovery phrase
  • Trick the owner into signing a transaction
  • Break into the storage location
  • Guess every theoretically possible BIP39 phrase

Instead, the attacker attempts to reduce the possible search space by recreating or constraining the conditions under which the wallet secret was generated.

Once a candidate seed produces a known wallet address or public key, that public blockchain information can help validate whether the candidate is correct.

This changes the familiar security question.

It is no longer only:

“Did anyone see my recovery phrase?”

It also becomes:

“Was my recovery phrase generated with enough unpredictable entropy in the first place?”

A Firmware Update Does Not Repair an Existing Seed

This is the most important practical detail.

Updating affected firmware corrects the generation process for new wallets. It does not add randomness to a recovery phrase that already exists.

A recovery phrase is not dynamically strengthened when the device software changes.

If an affected seed already controls funds, installing the update while continuing to use the same recovery phrase does not remove the original weakness.

Coinkite’s current migration guidance is broadly:

  1. Install the corrected firmware for the exact device and release track.
  2. Generate an entirely new recovery phrase.
  3. Record and verify the new backup.
  4. Verify the new wallet fingerprint and receiving address.
  5. Send a small test transaction.
  6. Confirm that the test funds arrived in the new wallet.
  7. Move the remaining funds only after successful verification.

The company specifically warns users to migrate calmly because a rushed transfer can create a more immediate risk than the vulnerability being addressed.

Moving the Same Seed to Another Device Does Not Help

A common misunderstanding is that an exposed or weakened hardware wallet can be fixed by importing its recovery phrase into a new device.

That changes the signing device.

It does not change the wallet secret.

If the seed itself was generated with insufficient randomness, restoring that seed on Ledger, Trezor, another COLDCARD, or any compatible wallet preserves the same underlying risk.

The secure solution requires a genuinely new recovery phrase generated through a corrected and trusted process, followed by an on-chain transfer to addresses controlled by that new seed.

Never type the old phrase into an online “migration tool” or website claiming to repair it.

There is no legitimate web form that can add entropy to an existing recovery phrase.

Does This Mean All COLDCARD Users Are Affected?

No.

The official advisory defines specific affected firmware ranges and several important exceptions.

Coinkite states that seeds supplemented during creation with at least 50 fair, independent, private dice rolls are not considered at risk from this random-number-generation issue alone. A strong and unique BIP39 passphrase may also provide an additional barrier, although Coinkite still recommends migration because the passphrase does not repair the original seed.

Users should consult the latest official advisory rather than relying on social-media summaries.

Do not guess based only on:

  • The appearance of the device
  • When the device was purchased
  • The currently installed firmware
  • Whether the wallet has remained dormant
  • Whether the recovery phrase has ever been exposed

The relevant question is which firmware generated the seed and whether independent entropy or a strong passphrase was used.

Does This Prove That Self-Custody Is Broken?

No—but it exposes a difficult reality.

Self-custody removes dependence on an exchange or traditional custodian. It does not remove dependence on:

  • Firmware quality
  • Hardware design
  • Random-number generation
  • Supply-chain integrity
  • Recovery procedures
  • Transaction verification
  • The user’s operational discipline

A person using self-custody exchanges counterparty risk for a different set of risks.

That does not make self-custody inherently worse. It means “not your keys, not your coins” is only the beginning of the security model—not the entire model.

A hardware wallet should not be trusted solely because it is offline, open source, expensive, air-gapped, or popular.

Each characteristic addresses only part of the threat model.

Open Source Did Not Automatically Prevent the Bug

COLDCARD firmware is publicly available.

That visibility can help independent researchers inspect the implementation, but public code does not guarantee that every execution path has been correctly reviewed.

Coinkite explained that the intended hardware random-number-generator code existed in the firmware binary. The review failure involved which implementation the wallet-generation path actually reached across connected software components.

This is an important distinction.

Security review cannot stop at confirming that the correct component exists somewhere in the codebase.

It must also verify:

  • Which function is reached at runtime
  • How randomness flows through the complete wallet-generation process
  • Whether build configurations change behavior
  • Whether fallback paths are cryptographically appropriate
  • Whether updates preserve the intended entropy guarantees
  • Whether compiled binaries correspond to reviewed source code

Open source enables inspection.

It does not perform the inspection by itself.

What Should Buyers Ask Before Choosing a Hardware Wallet?

Most product comparisons focus on screen size, supported coins, Bluetooth, battery life, and price.

Those features matter, but the COLDCARD incident shows why buyers should ask deeper questions.

Seed generation

  • Which random sources contribute to wallet creation?
  • Is randomness generated inside a secure element, the main processor, or both?
  • Are multiple independent entropy sources combined?
  • Has the complete generation path been reviewed?

Firmware security

  • Is firmware independently audited?
  • Are security reports publicly available?
  • Are reproducible or verifiable builds supported?
  • How quickly does the manufacturer publish advisories?

Recovery model

  • Can the user verify the backup before depositing funds?
  • Is an optional passphrase supported?
  • Are multi-share or multi-device recovery options available?
  • Can users safely migrate without entering secrets online?

Transaction verification

  • Does the device have an independent screen?
  • Can receiving addresses be confirmed on the device?
  • Are transaction amounts and destinations displayed clearly?
  • How are complex smart-contract actions handled?

Incident response

  • Does the manufacturer identify exact affected versions?
  • Are migration instructions clear?
  • Does it explain what the update fixes—and what it cannot fix?
  • Are users told to send a test transaction before moving the full balance?

A glossy product page rarely answers all of these questions.

They still deserve to be asked.

Secure Generation, Secure Signing, Secure Backup

Hardware-wallet security has at least three distinct stages.

Secure generation

The recovery phrase must begin with enough unpredictable randomness.

A physically protected backup cannot compensate for a weak secret.

Secure signing

The device should let the user confirm addresses and transaction details through a trusted workflow.

Strong seed generation cannot prevent someone from intentionally authorizing the wrong transaction.

Secure backup

The recovery information must remain private, durable, readable, and recoverable.

A correctly generated wallet can still be lost when its only backup is damaged, discarded, photographed, or entered into a phishing website.

I have been organizing practical guides to hardware-wallet selection, recovery security, address verification, and offline backup planning at CryptoSafeKit.

The goal is not to claim that one brand or accessory eliminates every risk. It is to help users understand the complete security process before they place meaningful assets behind a single recovery phrase.

A metal seed backup can improve physical durability compared with ordinary paper, but it cannot repair weak entropy, stop malicious signing, or protect a phrase stored in an obvious location.

Every layer has a specific job.

What This Incident Should Change

The wrong conclusion is:

“COLDCARD failed, so another brand must be perfectly safe.”

No hardware wallet deserves unlimited trust.

The more useful conclusion is:

“I need to understand how my wallet creates, signs with, and recovers its keys.”

For current hardware-wallet owners, that means:

  • Subscribe to official security advisories
  • Record which device and firmware created each wallet
  • Verify receiving addresses on trusted hardware
  • Maintain a tested recovery plan
  • Separate long-term storage from active accounts
  • Avoid keeping every asset under one recovery phrase
  • Migrate when a seed—not merely a device—is compromised
  • Never enter a recovery phrase into an online repair or migration service

Self-custody security cannot be completed once and forgotten forever.

The Most Important Question Comes Before the First Deposit

Most users ask:

“How will this device protect my recovery phrase?”

After this incident, another question deserves equal attention:

“How was the recovery phrase created?”

A hardware wallet may remain offline.

Its backup may remain hidden.

Its owner may avoid every phishing link.

But when the underlying secret is predictable enough to reproduce, the usual defenses can fail without anyone touching the device.

Security begins before the wallet receives its first transaction.

It begins with the quality of the secret controlling it.

Has this incident changed what you would ask before buying a hardware wallet—or has it reduced your confidence in self-custody altogether?

Share your view in the comments. This is a discussion the hardware-wallet industry should not avoid.

This article is for educational and security-awareness purposes only. It does not constitute financial, legal, investment, or personalized cybersecurity advice. Potentially affected users should follow the latest official Coinkite advisory. Never enter a recovery phrase, private key, PIN, or passphrase into a website, unsolicited application, support message, or cloud service.

How do you rate this article?

5



CryptoSafeKit
CryptoSafeKit

CryptoSafeKit shares practical, independent guides on crypto security, self-custody, hardware wallets, recovery phrase protection, phishing prevention, and safer Web3 habits. Our goal is to help everyday users understand risks, avoid common mistakes, and take greater control of their digital assets.

Publish0x

Send a $0.01 microtip in crypto to the author, and earn yourself as you read!

20% to author / 80% to me.
We pay the tips from our rewards pool.

Page not displaying correctly?