In July 2026, Coinkite disclosed a vulnerability affecting the generation of cryptocurrency wallet seeds on certain Coldcard firmware versions. The issue was serious because a recovery seed is the foundation from which a wallet's private keys are derived.
The incident was unusual for another reason: the devices themselves were not remotely hacked. According to Coinkite, attackers were able to regenerate vulnerable private keys offline because affected wallets had been created with weakened randomness.
That distinction matters.
This was not a case where somebody remotely connected to a Coldcard and extracted a seed from the device. The problem occurred earlier, when some wallets were created.
What Happened in the 2026 Coldcard Incident?
On July 30, 2026, Coinkite published a security advisory concerning weakened seed generation. The company later explained that the issue was connected to a firmware integration problem involving the randomness path used during wallet creation.
Coldcard was designed to use hardware-generated randomness when creating seeds. However, during a software migration in 2021, a code path resolved the randomness request to a software pseudo-random number generator instead of the intended hardware random-number generator.
The result was a much smaller effective search space for some seeds than the cryptographic design required.
Coinkite's disclosure history describes the problem as a build-integration and symbol-resolution defect, rather than a hardware RNG failure.
The distinction is technically important: the hardware random-number generator existed and functioned, but the affected seed-generation path did not use it as intended.
Why Is Randomness So Important for a Hardware Wallet?
A cryptocurrency wallet seed must be unpredictable.
The security model assumes that an attacker cannot realistically enumerate enough possible seeds to discover the one controlling a particular wallet.
For a standard 12-word BIP-39 mnemonic, the underlying entropy is typically 128 bits. A 24-word BIP-39 mnemonic normally represents 256 bits of entropy before the checksum is considered.
The important concept is not the number of words by itself. It is the unpredictability of the entropy from which those words are produced.
That is why a hardware wallet's random-number generation is one of the most important parts of its security architecture.
How the Coldcard Randomness Problem Happened
The technical explanation involves several pieces of software rather than a single broken component.
The intended wallet-generation process relied on hardware-generated random data.
During the 2021 libNgU migration, a randomness request resolved differently from the intended Coldcard-specific hardware path.
The affected path used MicroPython's Yasmarang pseudo-random number generator rather than the dedicated hardware RNG.
This is one of the most important lessons. Weak randomness does not necessarily produce obviously strange-looking seed words.
Normal users could not simply look at a recovery phrase and determine whether its underlying entropy was sufficiently unpredictable.
Researchers and blockchain analysts observed funds moving from wallets created with affected seeds.
Why Normal Users Could Not See the Problem
A recovery phrase is a representation of cryptographic entropy. It is not a visual indicator of how that entropy was generated.
Two 24-word recovery phrases can look equally random to a person while being generated by radically different underlying processes.
One may have been created from strong hardware randomness. Another may have been produced from a predictable algorithm.
The words themselves do not reveal that difference.
How Attackers Could Exploit a Weak Seed
The attack model was different from a traditional malware infection.
Instead of breaking into the victim's computer and stealing a recovery phrase, an attacker could generate candidate seeds offline and compare the resulting addresses against public blockchain data.
If a vulnerable seed came from a sufficiently small search space, an attacker could search that space for candidate keys corresponding to funded addresses.
Once the correct private key was reconstructed, the attacker could create valid blockchain transactions without ever physically touching the victim's hardware wallet.
| Traditional device compromise | Coldcard seed-generation incident |
|---|---|
| Attacker attempts to access the device or computer. | Attacker reconstructs vulnerable keys offline. |
| Private information may be extracted directly. | The recovery seed itself was insufficiently unpredictable. |
| Malware or remote access may be involved. | No remote takeover of the Coldcard was required. |
| Cleaning the computer may remove the malware. | Updating firmware does not repair an existing vulnerable seed. |
How Serious Was the Incident?
The incident resulted in real losses.
Trezor's August 28 analysis reported that approximately 1,367 BTC, worth around $88 million at the time of its analysis, had moved across roughly 4,585 addresses, while noting that estimates can differ and that not all observed waves necessarily had the same attacker.
The exact victim count and attribution should therefore be treated carefully rather than reduced to a single headline number.
What is not in dispute is the underlying security lesson: predictable wallet-generation entropy can turn a supposedly offline wallet into a target that can be attacked using public blockchain information.
The Most Important Lesson: Offline Does Not Mean Automatically Secure
Cold storage removes many remote attack paths. It does not eliminate bugs in firmware, cryptographic libraries, build systems, backup procedures or wallet-generation logic.
A hardware wallet is better understood as a security system rather than simply a small device that stores crypto.
The Coldcard incident demonstrates that all of these layers matter at the same time.
Which Coldcard Firmware Versions Were Affected?
Coinkite's current security advisory identifies affected firmware ranges across several Coldcard models and release tracks.
The important point is that the affected range was not limited to one old device. The advisory covers Mk2/Mk3, Mk4, Mk5 and Q depending on the firmware version and release track.
| Model / track | Minimum fixed version | Important point |
|---|---|---|
| Mk2 / Mk3 | 4.2.0 | Seeds generated by earlier affected firmware require separate evaluation and migration. |
| Mk4 / Mk5 standard | 5.6.0 | Current recommended standard release is newer than the minimum fix. |
| Q standard | 1.5.0Q | Current recommended standard release is newer than the minimum fix. |
| Mk4 / Mk5 Edge | 6.6.0X | Edge releases must be evaluated separately from standard firmware. |
| Q Edge | 6.6.0QX | Use the fixed release appropriate to the Edge track. |
According to the current Coldcard Security Status page, the recommended standard releases as of September 4, 2026 are Mk4/Mk5 5.6.2 and Q 1.5.2Q.
Why Updating the Firmware Is Not Enough
This is probably the most important practical point for anyone who owned an affected device.
Suppose a wallet generated a seed while the vulnerable code path was active. Updating the device later changes the firmware, but it does not change the recovery phrase that already exists.
The private keys derived from that seed remain mathematically connected to the same seed.
Therefore, the security problem cannot be solved simply by installing a newer firmware version.
What About Seeds Created With Dice?
Coinkite's advisory includes an important exception concerning independent dice-generated entropy.
If a user supplied enough fair, independent and private dice rolls during seed creation, that independently generated entropy could substantially change the security properties of the resulting seed.
The advisory states that 50 to 98 independent private rolls provide at least 128 bits of entropy from the dice input alone, while 99 or more provide approximately 256 bits.
However, if you are uncertain about how many rolls were used, whether they were fair and independent, or whether they remained private, the conservative approach is to follow the official migration guidance.
What If You Used a BIP-39 Passphrase?
A strong, unique BIP-39 passphrase can create an additional security barrier because the passphrase is not contained in the 24-word recovery phrase.
Coinkite explains that an attacker who reconstructs an affected seed would still need to discover the passphrase to access accounts derived using that passphrase.
However, a passphrase does not repair the underlying seed-generation weakness.
If the passphrase is weak, reused or otherwise guessable, it should not be treated as a reliable safety net.
The distinction between a PIN and a BIP-39 passphrase is also important. A device PIN protects access to the hardware wallet; a BIP-39 passphrase changes the wallet derived from the recovery seed.
For a deeper explanation of passphrases, see: What Is a Hardware Wallet Passphrase?
What Did Coinkite Change?
The remediation did not stop at changing a single line of code.
Coinkite's later security releases describe additional changes around seed generation, transaction review, USB data handling, firmware-update validation, RNG error handling, wallet state and other security boundaries.
The August 20 security update also introduced stronger checks around the hardware TRNG path, while the later 5.6.2 release continued the security work.
Why Fail-Closed Design Matters
One of the most useful engineering lessons from the incident is the importance of failing safely.
If a wallet cannot obtain the cryptographic randomness it requires, a secure design should not silently continue using an unsafe substitute.
Instead, the operation should stop.
Trezor's post-incident analysis describes this philosophy explicitly. Its production firmware is designed so that wallet generation does not quietly fall back to a software randomness source when the intended randomness path is unavailable.
Why Statistical Randomness Tests Are Not Enough
A particularly interesting aspect of the incident is that weak seeds can still look random.
A pseudo-random generator can produce output that passes many superficial statistical tests while remaining predictable if its internal state or seed can be reconstructed.
Cryptographic randomness is therefore not simply about whether a sequence "looks random."
The question is whether an attacker can predict or reproduce the output with feasible resources.
| Question | Why it matters |
|---|---|
| Does the output look random? | Useful for detecting obvious statistical problems, but not sufficient. |
| Is the source unpredictable? | Essential for cryptographic key generation. |
| Can an attacker reconstruct the generator state? | If yes, apparently random output may become predictable. |
| Does the implementation use the intended RNG? | A secure hardware RNG is useless if the critical code path bypasses it. |
| Does the system fail safely? | A failure should not silently downgrade security. |
Could a User Have Detected the Vulnerable Seed?
In normal circumstances, not reliably by looking at the recovery phrase.
The weakness was in the generation process, not a visible formatting error in the resulting words.
That is why independent entropy procedures, reproducible firmware, code review, testing and fail-closed engineering are important parts of hardware-wallet security.
Users should not be expected to manually determine whether a cryptographic random-number generator has been correctly wired into a firmware build.
Does This Mean Hardware Wallets Are Unsafe?
That conclusion would be too broad.
The incident demonstrates that hardware wallets can contain serious vulnerabilities. It does not establish that all hardware wallets share the same flaw.
Security has to be evaluated at the level of the particular device, firmware, implementation and operational process.
The useful lesson is not "hardware wallets do not work."
The useful lesson is that hardware security is one layer in a larger system.
What the Incident Teaches About Security Marketing
Security claims such as "air-gapped," "secure element," "open source" or "hardware RNG" describe useful properties, but none of them individually proves that the entire wallet-generation process is secure.
A device can have sophisticated hardware and still suffer from an implementation mistake.
Conversely, a security incident does not mean that every other part of the device is defective.
The correct approach is to examine the evidence: what failed, which versions were affected, what was fixed, how the fix was independently reviewed, and whether existing wallets require migration.
What Should a Hardware Wallet User Learn From the Incident?
The most valuable lesson is not to memorize one firmware version or one company's vulnerability. It is to understand how hardware-wallet security actually works.
- A hardware wallet is a security system, not just a physical device.
- Seed generation is one of the most critical operations performed by the wallet.
- Firmware updates can fix future wallet creation without repairing an existing seed.
- Security claims should be supported by inspectable engineering and testing.
- When an official advisory says an existing seed must be migrated, treat that as a separate operation from updating firmware.
How to Approach a Hardware Wallet Security Advisory
When a wallet manufacturer publishes a security advisory, avoid reacting only to the headline. First establish whether your specific device and firmware are inside the affected range.
Record the hardware model and whether it uses a standard or preview/Edge firmware track.
Compare the installed version with the manufacturer's current advisory rather than relying on forum posts or social-media summaries.
Some vulnerabilities affect wallets generated during a particular firmware range rather than every wallet ever used with the device.
If the advisory says the existing seed is affected, do not assume a firmware update is enough.
Install the appropriate fixed firmware and follow the official instructions for creating and backing up the replacement wallet.
Test the new backup and recovery process before treating the migration as complete.
What You Should Never Do During a Security Incident
- Do not give your recovery phrase to "support" because of a vulnerability announcement.
- Do not download emergency firmware from a random link.
- Do not trust screenshots of firmware files or instructions posted by unknown accounts.
- Do not assume a firmware update automatically repairs an existing seed.
- Do not rush a migration without verifying the replacement backup.
- Do not send funds to an address supplied by an unverified person claiming to help.
For general recovery-phrase protection, see our Seed Phrase Security guide .
How This Incident Connects to Other Hardware-Wallet Risks
The Coldcard incident is different from phishing, clipboard malware, address poisoning and transaction-signing attacks, but the underlying lesson is similar: security failures can occur at different points in the self-custody chain.
| Threat | Main weakness exploited | Primary defense |
|---|---|---|
| Weak seed generation | Predictable wallet creation | Secure randomness and verified firmware |
| Address poisoning | Human address-recognition habits | Independent destination verification |
| Clipboard malware | Compromised computer software | Verify destination on the hardware wallet |
| Phishing | Social engineering | Never disclose recovery secrets |
| Malicious transaction | User signing without checking details | Clear transaction verification |
That is why no single security feature should be treated as a complete solution.
Cold Storage Is a Process
The phrase "cold storage" often makes people think only about keeping a private key offline. In practice, secure self-custody is a chain of decisions.
The seed must be generated securely. The backup must remain private. The firmware must be trustworthy. Transactions must be verified. Updates must be authenticated. Recovery must be tested.
A failure in one of those stages can undermine the security provided by the others.
Frequently Asked Questions
What was the Coldcard vulnerability in 2026?
Certain Coldcard firmware versions generated wallet seeds using a weaker software randomness path instead of the intended hardware randomness path. This reduced the effective security of affected seeds.
Was Coldcard remotely hacked?
According to Coinkite's published incident record, the devices themselves were not remotely accessed or taken over. Attackers exploited the predictable seeds by reconstructing the corresponding private keys offline.
Does updating Coldcard firmware fix an affected wallet?
No. Updating fixes future seed generation. An existing seed generated by affected firmware remains the same and must be evaluated according to the official migration guidance.
Were all Coldcard devices affected?
No. The published advisory identifies specific firmware ranges across different Coldcard models and release tracks. Users should check their exact model and firmware version against the current official security status.
What is the current recommended Coldcard firmware?
As of September 2026, Coldcard's security status page lists Mk4/Mk5 5.6.2 and Q 1.5.2Q as the current recommended standard releases. Fixed releases also exist for older and Edge tracks.
Can a strong passphrase protect an affected seed?
A strong, unique BIP-39 passphrase can provide an additional barrier because it is separate from the seed. However, it does not repair the weak seed itself. Follow the manufacturer's migration guidance if the seed is affected.
Could someone see from my recovery words that the seed was weak?
Not reliably. The recovery words do not provide a simple visual indicator of whether the entropy-generation process was secure.
Does this mean every hardware wallet is dangerous?
No. It demonstrates that hardware wallets depend on secure hardware, firmware, cryptographic implementation, testing and operational procedures. Different products have different architectures and vulnerabilities.
The Bigger Lesson for Crypto Security
The Coldcard incident is a useful reminder that "offline" is not the same as "mathematically invulnerable."
Hardware wallets reduce important attack surfaces, but their security ultimately depends on the correctness of the systems that generate, store and use cryptographic secrets.
For users, the practical response is not panic. It is verification.
Related ColdStorageHub Guides
Official Sources & Further Reading
- Coinkite — Coldcard Security Advisory
- Coldcard — Current Security Status
- Coinkite — Technical Deep Dive into the Entropy Issue
- Coinkite — Security Update: Seed Generation, Transaction Integrity and Data Isolation
- Trezor — Lessons from the Coldcard Incident
- Trezor — Coldcard Vulnerability: Trezor Devices Are Not Affected
- Ledger — El incidente de Coldcard: ¿Cómo sucedió esto?
- COLDCARD Firmware — Public Source Repository
Educational disclaimer: This article is for cryptocurrency security education. Firmware versions and security guidance can change. If you own an affected device, use the manufacturer's current official security advisory and migration instructions rather than relying solely on this summary.