A serious Coldcard security issue has exposed a basic truth about Bitcoin self-custody: a hardware wallet can be offline, protected by a PIN, and functioning exactly as expected while still producing a weak wallet if the seed-generation process fails.
This was not a failure of Bitcoin, BIP39, or the blockchain. It was a failure in the process used by affected Coldcard firmware to generate the randomness behind certain wallet seeds.
That distinction matters because the Bitcoin protocol can remain secure while funds are still exposed through predictable private keys.
Security notice: Never enter your seed words, passphrase, PIN, dice sequence, private keys, wallet file, or recovery screenshots into a website, form, chat, email, or support message. Bitcoin Plaster will never ask for them.
Last verified: August 3, 2026
Status: Active incident coverage. The vendor investigation remains ongoing, and this page should be updated if the official scope changes.
The short explanation
A Bitcoin wallet seed must be created from enough unpredictable randomness, known as entropy.
Coinkite says affected Coldcard firmware did not use the intended hardware random-number path correctly during seed generation. On older affected models, the resulting search space may have been dramatically smaller than intended. Newer affected models received additional entropy from secure elements, but Coinkite still estimates that some seeds fell below the expected security target.
An attacker does not need to break Bitcoin cryptography when a wallet chooses its secret from a search space small enough to examine. The attacker can generate candidate seeds, derive their addresses, compare them with public blockchain activity, and spend funds when a match is found.
The central consequence is simple:
A firmware update can correct future seed generation, but it cannot add randomness to a seed that already exists.
An affected seed remains affected until the Bitcoin is moved to a wallet controlled by a completely new seed.
What happened
According to Coinkite's technical explanation, a 2021 integration change moved part of Coldcard's cryptographic functionality to a new library path. The cryptographic library itself was not the problem. The failure occurred in how the seed-generation path selected its source of randomness.
Instead of consistently reaching the intended hardware random-number generator, the affected path could resolve to a software pseudorandom-number-generator fallback. A build-time check did not stop this from happening because the relevant configuration test checked whether a setting existed, rather than whether it was enabled correctly.
That is a small implementation distinction with enormous consequences.
A hardware wallet can have a secure element, an air gap, open-source firmware, transaction verification, and physical protections. None of those features can compensate for a seed that was selected from a predictable or substantially reduced set of possibilities.
Every private key, address, and signature in the wallet ultimately depends on that original secret.
Why this was not a Bitcoin hack
Bitcoin did not generate the affected seeds. Coldcard firmware did.
Bitcoin's cryptography still requires valid private keys to authorize spending. The vulnerability made some private keys easier to reconstruct because the secrets may not have been generated with the intended level of unpredictability.
This is the difference between breaking a lock and discovering that a lock manufacturer produced keys from a much smaller set than customers were promised.
The lock can still work exactly as designed. The problem is that an attacker may be able to search the reduced key set.
This incident therefore concerns wallet implementation security, not a failure of:
- the Bitcoin network;
- transaction signatures;
- the BIP39 word list;
- blockchain consensus;
- proof of work;
- hardware wallets as a general category.
It does, however, show why users must distinguish protocol security from the security of the tools used to generate and protect their keys.
Why entropy matters
Entropy is the unpredictability used to choose a cryptographic secret.
A secure seed should be selected from a search space so large that testing every realistic possibility is computationally infeasible. Each lost bit of entropy cuts the remaining search space in half.
This means a reduction from 128 bits to 72 bits is not a modest reduction of roughly 44 percent. It is an exponential collapse in the number of possibilities an attacker must examine.
Coinkite's current technical explanation gives preliminary estimates of approximately:
- 40 bits of effective search space for affected Mk2 and Mk3 seed generation under the vendor's current attack assumptions;
- 72 bits of entropy for affected Mk4, Mk5, and Q seeds, due to additional secure-element entropy mixed into the process;
- 128 bits as the expected security target for the affected generation path.
These figures are vendor estimates from an ongoing investigation, not permanent universal measurements. They should not be treated as a complete benchmark of attack cost, hardware requirements, or time to compromise every individual wallet.
The practical point does not depend on pretending that every affected seed is equally easy to find. The confirmed issue is that the seed-generation process did not provide the security margin users expected, and the vendor recommends replacement and migration.
Which Coldcard seeds are in the official scope
The relevant question is not which firmware is installed today.
The relevant question is:
Which device model, release track, firmware version, and entropy process were used when the current seed was created?
As of August 3, 2026, Coinkite's advisory identifies the following scope:
| Coldcard model | Seed-generation firmware in scope | Fixed release for new seed generation |
|---|---|---|
| Mk2 and Mk3 | 4.0.1 through 4.1.9, inclusive | 4.2.0 or later |
| Mk4 and Mk5, Standard track | Earlier than 5.6.0 | 5.6.0 or later |
| Mk4 and Mk5, Edge track | Earlier than 6.6.0X | 6.6.0X or later |
| Q, Standard track | Earlier than 1.5.0Q | 1.5.0Q or later |
| Q, Edge track | Earlier than 6.6.0QX | 6.6.0QX or later |
Standard and Edge are separate firmware tracks. A larger leading version number does not prove that a release from a different track contains the fix.
Coinkite states that TAPSIGNER, OPENDIME, and SATSCARD are not affected because they use different codebases.
This table describes the vendor-confirmed operational scope. It does not prove that every seed in the listed range has already been discovered, targeted, or stolen. It also should not be stretched into claims about products or models that the current advisory does not name.
Why updating the firmware does not fix the existing wallet
A seed phrase represents an existing cryptographic secret.
Updating firmware changes how the device behaves from that point forward. It does not rewrite the seed already controlling the wallet.
A firmware update does not:
- regenerate the recovery phrase;
- alter the existing private keys;
- add entropy to the original seed;
- change the wallet fingerprint;
- create new receiving addresses from new key material;
- make the same words safer when restored elsewhere.
This is why importing the affected seed into a different hardware wallet does not solve the problem. The device changes, but the private keys remain the same.
The correct security boundary is a new seed and new wallet, followed by an on-chain transfer from the old wallet to addresses derived from the new seed.
Read the full migration procedure before moving funds:
How to Move Bitcoin From a Potentially Weak Coldcard Seed Without Making It Worse
Why an air gap did not prevent this
An air gap changes how a signing device communicates with other devices. It can reduce exposure to certain remote, USB, or host-computer attack paths.
It does not prove that a seed was generated with sufficient randomness.
A wallet can remain completely offline and still create predictable keys if its random-number generation fails. The weakness is embedded in the seed before the first address is used and before the first transaction is signed.
This is why security labels must be interpreted narrowly:
- Air-gapped describes a communication model.
- Secure element describes protection assigned to particular hardware components.
- Open source allows code inspection.
- Reproducible builds help verify that a binary corresponds to published source.
- Bitcoin-only reduces software scope.
None of these labels, alone, proves that the complete seed-generation path is correct.
What dice rolls change
Coinkite says the issue affected device-generated entropy. It did not remove independent entropy that users supplied correctly through dice during the original seed-creation process.
Under the current advisory:
- 50 to 98 fair, independent, private dice rolls contributed at least approximately 128 bits of entropy from the dice input alone;
- 99 or more such rolls contributed approximately 256 bits;
- fewer than 50 rolls, an unknown number of rolls, exposed rolls, or uncertainty about the procedure should lead the user back to the migration guidance.
Coinkite says it does not consider a resulting seed at risk from this RNG issue alone when at least 50 valid private dice rolls were incorporated into the final seed.
That is a bounded exception, not a general claim that "dice make everything safe."
The exception depends on the rolls being:
- fair;
- independent;
- private;
- entered correctly;
- incorporated when the current seed was created;
- remembered with enough certainty to support the conclusion.
Rolling dice now does not strengthen an old seed. The new entropy only matters when it is used to generate a new cryptographic secret.
What a BIP39 passphrase changes
A BIP39 passphrase is not the Coldcard PIN.
The PIN protects access to the physical device. A BIP39 passphrase participates in wallet derivation and creates a different wallet from the same seed words.
A strong, unique, secret passphrase can add an independent barrier. An attacker who reconstructs the affected mnemonic would still need the passphrase to reach that passphrase-protected wallet.
But the quality of that protection depends entirely on the passphrase.
A short, common, patterned, quoted, reused, or human-predictable passphrase may be guessable. A passphrase typo also creates a valid but different wallet, which creates an additional operational risk during migration.
Most importantly, a passphrase does not repair the underlying seed. Coinkite still recommends migration from affected seeds, even when a strong passphrase reduces immediate exposure.
Single-signature and multisignature risk are different
Single-signature wallets
A single-signature wallet controlled by one affected seed has the clearest exposure.
If an attacker reconstructs that seed, no additional signer is required. The attacker can produce a valid transaction using the corresponding private keys.
Multisignature wallets
Multisignature can reduce single-device risk only when the spending threshold depends on independently generated keys.
The decisive question is:
Can the wallet's spending threshold be satisfied entirely with affected Coldcard-generated keys?
In a two-of-three wallet:
- one affected key plus two independently generated keys is not compromised by the affected key alone;
- two affected keys may be enough to satisfy the threshold;
- three affected keys preserve the multisignature structure but may share the same generation failure.
The protection comes from independent key-generation environments, not from the number of devices by itself.
Multisignature migration can also expose scripts and public keys when a transaction is broadcast. Users with a potentially affected multisignature quorum should avoid improvising under pressure and should obtain experienced technical help.
What affected users should do
Do not begin by entering secrets into a website or by resetting devices at random.
First classify the seed:
- Identify the exact Coldcard model that created it.
- Identify the firmware version active at seed creation.
- Determine whether Standard or Edge firmware was used.
- Confirm whether the seed was generated on the Coldcard or imported from elsewhere.
- Determine whether at least 50 valid private dice rolls were incorporated.
- Determine whether a BIP39 passphrase protects the funded wallet.
- For multisignature, inventory every signer and the spending threshold.
When the seed falls within the affected scope and the dice exception does not clearly apply, the safe endpoint is a completely new seed and a new wallet.
At a high level, the migration sequence is:
- Install and verify fixed firmware on the destination generation device.
- Generate a completely new seed.
- Record and verify the new backup.
- Verify a receive address on the destination device screen.
- Send a small test transaction.
- Confirm the new wallet works and can be recovered.
- Move the remaining funds.
- Keep the old backup until the entire migration is confirmed.
A second hardware wallet can simplify this process by keeping the old and new wallets physically separate, but Coinkite says a fixed Mk2 or Mk3 can generate a valid replacement seed. Purchasing a different device is not the technical requirement. Generating a genuinely new seed through a fixed or independent process is the requirement.
What not to do
Do not:
- restore the same seed onto a new device and assume the risk is gone;
- assume the firmware installed today determines the quality of a seed created years ago;
- treat a PIN as a BIP39 passphrase;
- assume any passphrase is automatically strong;
- claim dice protection when the roll count or procedure is uncertain;
- enter seed words into a "seed checker";
- send seed words to support;
- photograph or upload recovery material;
- destroy the old backup before the migration is fully verified;
- rush a complex multisignature migration without understanding the quorum;
- move funds from an unaffected wallet solely because of generalized panic.
The incident requires urgency, but panic can create immediate and irreversible mistakes.
What remains unproven
A careful incident report must separate the operational warning from claims that current public evidence does not fully establish.
The official advisory supports the affected scope, fixed firmware matrix, reduced-entropy estimates, dice exception, passphrase boundary, and need for seed replacement.
It does not, by itself, prove:
- that every public transaction discussed online was caused by this vulnerability;
- the owner, device, or firmware behind a specific blockchain movement;
- a universal attack cost for every affected seed;
- the exact time required to compromise an individual wallet;
- that every alternative hardware wallet is immune to implementation failures;
- that one security feature can guarantee the safety of a complete custody system.
Public blockchain movements can be suspicious or consistent with an incident without constituting complete attribution evidence.
Bitcoin Plaster will not use unstable loss figures or unproven theft attribution as the central claim of this page.
Why this incident matters beyond Coldcard
The immediate responsibility is helping affected users understand the scope and migrate safely.
The broader lesson is that self-custody is a system, not a product purchase.
A complete security model includes:
- entropy generation;
- firmware and build configuration;
- hardware boundaries;
- transaction verification;
- seed backup quality;
- recovery testing;
- passphrase design;
- signer independence;
- software dependencies;
- vendor disclosure and response;
- the user's ability to operate the setup correctly.
A hardware wallet is an important tool, but it does not remove the need to understand where keys come from, how they are backed up, and which failures can compromise the balance.
The correct response is not to declare self-custody impossible. It is to stop treating any single product label as a substitute for a complete security model.
Frequently asked questions
Was Bitcoin hacked?
No. The issue concerns seed generation in affected Coldcard firmware, not Bitcoin's cryptography or consensus rules.
Does installing fixed firmware repair my existing seed?
No. Fixed firmware corrects future seed generation. An affected existing seed must be replaced, and the funds must be transferred to a wallet derived from the new seed.
Does restoring the seed on another hardware wallet fix it?
No. Restoring the same words recreates the same private keys and the same risk.
Can an air-gapped wallet have a weak seed?
Yes. An air gap changes device communication. It does not guarantee correct entropy generation.
Do I have to buy a different hardware wallet?
No. Coinkite says a Coldcard running the appropriate fixed firmware can generate a replacement seed. A separate device may make migration easier and reduce operational confusion, but the non-negotiable requirement is a completely new seed generated through a fixed or independent process.
Am I protected if I used dice?
Coinkite's current advisory provides an exception when at least 50 fair, independent, private rolls were correctly incorporated into the final seed. When the count or procedure is uncertain, follow the migration guidance.
Am I protected by a passphrase?
A strong, unique BIP39 passphrase can reduce immediate exposure, but it does not repair the weak seed. Short or predictable passphrases may be guessable. The vendor still recommends migration.
Does this mean other hardware wallets are affected?
No. A Coldcard-specific implementation failure does not automatically apply to unrelated devices. Other products should be evaluated using their own architecture, evidence, advisories, and security boundaries.
Next step
First determine whether the seed controlling your Bitcoin falls within the official scope. Then follow a controlled migration process rather than making changes from panic.
- Exposure check: Was My Coldcard Seed Affected? A Step-by-Step Check
- Migration guide: How to Move Bitcoin From a Potentially Weak Coldcard Seed Without Making It Worse
- Security-model background: What a Hardware Wallet Does Not Solve
This incident page does not contain product recommendations or affiliate calls to action. Its purpose is to establish the problem, define the verified scope, and direct affected users toward safe next steps.
Update log
August 3, 2026
- Verified the affected-model and fixed-firmware matrix against Coinkite's current advisory.
- Included Mk2 and Mk3 firmware 4.0.1 through 4.1.9 in the official scope.
- Included the Standard and Edge fixed releases for Mk4, Mk5, and Q.
- Preserved the distinction between confirmed operational guidance and unproven blockchain-loss attribution.
Primary sources
- Coinkite, Coldcard Security Advisory, published July 30, 2026 and updated August 1, 2026.
- Coinkite, Technical Deep Dive into the Entropy Issue, published July 30, 2026 and updated August 1, 2026.