Report ID CTI-2026-0804-COLDCARD-RNG · Published 2026-08-04 · Classification TLP:GREEN · Severity CRITICAL
Author Dennis Kim / HoKwang Kim · [email protected] · @gameworkerkim
🌐 한국어 · English (this document) · 日本語 · 中文
Hardware-wallet security was never really about where you keep the key — it was about how the key gets made. Coldcard protected the former perfectly, and missed the latter for five years.
Table of Contents
- Executive Summary (TL;DR)
- Introduction — Isolation Held, Generation Failed
- Incident Timeline
- Root Cause Analysis — Macro-Existence Checks and the Fail-Open Structure
- Technical Vulnerability Analysis — Quantifying the Entropy Collapse
- Attack Chain Analysis — Offline Seed Reconstruction and On-Chain Sweeping
- Impact Quantification — Three Waves of Attack
- Survivor Analysis — What Kept Wallets Safe
- Response and Migration — What the Patch Cannot Fix
- Industry Implications — Re-Examining the Trust Model
- Korea Perspective — Regulatory Alignment and Recommendations for Domestic Exchanges
- Recommendations for Bitcoin Investors
- Detection, Response, and Prevention Checklist
- Conclusion
- References
- Appendix A — Impact Scope and Fixed-Firmware Cross-Reference Table
- Appendix B — Unconfirmed Items and Follow-Up Tracking Tasks
1. Executive Summary (TL;DR)
Between July 29 and August 2, 2026, a large-scale theft targeted seeds generated on Coldcard, the Bitcoin-only hardware wallet made by Canada's Coinkite. Per Galaxy Research, observed losses reached 1,367.05 BTC (approximately $88.6 million, roughly ₩123 billion), across 4,585 addresses. The attack proceeded in three waves and, at the time of writing, remains unresolved.
The essence of this attack is reconstruction, not intrusion. The attacker never touched a victim's device, never stole a PIN or seed phrase, and used no malware or phishing. A build-configuration inconsistency in Coldcard firmware from March 2021 routed seed generation away from the STM32 hardware random-number generator (TRNG) and into MicroPython's deterministic software PRNG (Yasmarang), which was seeded solely from the chip's unique ID and a timer register value and collected no additional entropy afterward. As a result, effective entropy collapsed from a designed 128 bits to approximately 40 bits on Mk2/Mk3, and approximately 72 bits on Mk4/Mk5/Q.
Forty bits is a search space exhaustible by consumer-grade hardware. The attacker enumerated candidate seeds offline, derived addresses per BIP-32/BIP-39 rules, then queried the public blockchain for balances to selectively sweep only the funded addresses. The blockchain's transparency was repurposed as the attacker's reconnaissance infrastructure.
Key facts at a glance
| Item | Details |
|---|---|
| Vulnerability introduced | Commit on 2021-03-01 (ckcc.rng_bytes → ngu.random.bytes); firmware v4.0.0 shipped 2021-03-17 |
| Exposure window | Approximately 5 years and 4 months |
| Effective entropy | Mk2/Mk3 ~40 bits, Mk4/Mk5/Q ~72 bits (design target: 128 bits) |
| Wave 1 | 2026-07-30 01:10–01:51 UTC, 41 minutes, 1,082.65 BTC / 1,196 addresses / ~$70.2 million |
| Cumulative losses | 1,367.05 BTC / 4,585 addresses / ~$88.6 million (as of 2026-08-02) |
| Vendor's first public notice | ~30 hours after Wave 1 ended |
| Movement of stolen funds | None — held unspent in attacker-controlled addresses |
| Victim profile | Average dormancy ~3.18 years; predominantly long-term individual holders |
| Unaffected products | TAPSIGNER, OPENDIME, SATSCARD (separate codebase); Trezor, Ledger, Block (Bitkey) |
One-sentence summary of this incident: cold storage protected the key, but it did not protect the moment the key was made.
2. Introduction — Isolation Held, Generation Failed
The hardware-wallet security model rests on two independent premises.
- The isolation premise — the private key never leaves a device that is not connected to the internet.
- The generation premise — that key is derived from randomness that cannot be guessed with any amount of computing resources.
Industry marketing, user education, and regulatory discussion as a whole have focused almost exclusively on the first premise. "Never connects to the internet" has been the centerpiece of hardware-wallet advertising, and Korea's own "cold-wallet custody ratio" metric for virtual-asset regulation is itself a quantification of the isolation premise.
In this incident, the isolation premise was never once broken. One victim, Canada's Jonathan Goodman, used a Coldcard that had been stored in a bank safe-deposit box, had never connected to the internet, and whose seed phrase he had disclosed to no one. He still lost 18.25 BTC in seven minutes on the evening of July 29, 2026.
What collapsed was the second premise. And once the second premise fails, the first premise provides no defensive value whatsoever. The attacker did not need to cross the perimeter. They simply re-derived, from the outside, a secret that had been created on the inside.
This structure is fundamentally different from the traditional incident-response paradigm of cybersecurity. There is no trace of intrusion, no log to detect, and the moment of compromise is not the moment of theft but the moment of key generation. Victims had already been compromised five years earlier, with no way of knowing it.
3. Incident Timeline
| Date/Time | Event | Notes |
|---|---|---|
| 2021-03-01 | Commit changes the seed-generation call from ckcc.rng_bytes to ngu.random.bytes |
Point at which the vulnerability was introduced |
| 2021-03-17 | Firmware v4.0.0 released | Start of distribution of vulnerable firmware |
| 2021-03 – 2026-07 | Vulnerable seeds continuously generated and put into circulation | Neither users nor the vendor were aware |
| Evening of 2026-07-29 (local) | Individual victim Jonathan Goodman loses 18.25 BTC over 7 minutes | First public victim testimony |
| 2026-07-30 01:10–01:51 UTC | Wave 1: 1,082.65 BTC / 1,196 addresses swept (41 minutes, spread across 6 blocks) | 3 intermediate blocks show a gap — consistent with batched broadcasting |
| 2026-07-30 (first 10 minutes) | ~$30 million stolen, high-value wallets hit first | Chainalysis analysis |
| 2026-07-31 (~30 hours after Wave 1 ended) | Coinkite publishes its first security advisory (covering Mk2/Mk3) | By this point the outflow was already complete |
| 2026-07-31 09:33 EDT | Fixed firmware released (Mk4/Mk5 v5.6.0+, Q v1.5.0Q+) | |
| 2026-08-01 | Coinkite expands the advisory — Mk4/Mk5/Q also affected, at ~72-bit entropy | Scope of impact widens |
| 2026-08-01 | Galaxy Research confirms Wave 2 — cumulative 1,158.66 BTC / 2,673 addresses / ~$75.1 million | 7 attacker-controlled addresses |
| 2026-08-02 | Galaxy Research confirms Wave 3 — an additional 207.73 BTC / 1,912 addresses | Targets smaller wallets, harder-to-trace pattern |
| 2026-08-02 | Cumulative total: 1,367.05 BTC / 4,585 addresses / ~$88.6 million | Attack ongoing |
| 2026-08-02 | Galaxy reports roughly 600 suspected attacker addresses to federal law enforcement and compliance vendors | |
| 2026-08-03 (present) | Stolen funds remain unmoved; investigation ongoing | Time of this report's writing |
4. Root Cause Analysis — Macro-Existence Checks and the Fail-Open Structure
4.1 Anatomy of the flaw
According to analysis published by Block's Bitcoin engineering team, the flaw unfolded in the following sequence.
[1] Coldcard production build configuration
MICROPY_HW_ENABLE_RNG = 0
(Coinkite deliberately set this to 0 because it supplies its own hardware RNG wrapper)
↓
[2] The libngu library
Checks only whether the macro "is defined" (an #ifdef-style check)
Does not check whether "the value is enabled" (an #if-style check)
↓
[3] Resulting determination
Because the macro is defined, the build is not mistakenly flagged as
"hardware RNG available" — it is instead bound to MicroPython's
default fallback path
↓
[4] Fallback PRNG: Yasmarang
Seed source = chip Unique ID (UID) + timer register
No new entropy collected after initialization
↓
[5] 2021-03-01 commit
ckcc.rng_bytes (direct STM32 hardware peripheral access)
→ ngu.random.bytes (the compromised libngu path)
↓
[6] SHA256d hashing
Hashing does not increase input entropy
2^40 inputs → at most 2^40 outputs
Step 6 is the crux. Many users, and some early reporting, assumed "it's hashed with SHA256, so surely it's safe" — but a cryptographic hash function provides compression and diffusion, not entropy creation. If there are 2^40 candidate inputs, there are at most 2^40 candidate outputs. This is the same structural error seen in a recurring string of RNG failures since 2012 (Debian OpenSSL, Android SecureRandom, the Profanity vanity-address generator, and others).
4.2 Why it went undetected for five years
| Factor | Explanation |
|---|---|
| Undetectable from output alone | Yasmarang's output passes statistical randomness tests (NIST STS, Dieharder, etc.). The problem is not distribution — it is the size of the search space |
| A build-time flaw | Reading the source code alone does not reveal it. It emerges from the interaction between build configuration and the library's conditional compilation |
| The open-source paradox | Because the firmware was open source, attackers could verify it just as easily as anyone else. Auditability is a bidirectional asset |
| No reproducibility verification | The release process had no cross-device entropy verification step to check whether two identical devices produce different seeds |
| Limits of automated auditing | Coinkite has stated it ran an AI-based audit of this same code weeks before the incident and did not find the flaw |
4.3 Observations on how the attacker may have found the flaw
Coinkite has raised the possibility that the attacker used AI to locate the flaw in the open-source firmware. At the same time, the company's own AI audit found nothing in the same code. This asymmetry is worth noting.
A defender's AI audit asks a broad, purposeless question: "does this code contain a vulnerability?" An attacker's use of AI asks a narrow, purpose-driven question: "how many total seeds can this device possibly produce?" The latter is a far easier question to answer. An LLM is not an oracle that substitutes for judgment — it is a tool that substitutes for computation, and the quality of a tool's output is proportional to the specificity of the question asked of it. This is a practically useful lesson for how defenders design AI-based audits.
That said, whether the attacker actually used AI remains, at this point, circumstantial inference, not a confirmed fact.
5. Technical Vulnerability Analysis — Quantifying the Entropy Collapse
5.1 Vulnerability summary
| Item | Details |
|---|---|
| Vulnerability class | CWE-331 (Insufficient Entropy), CWE-338 (Use of Cryptographically Weak PRNG) |
| Affected products | Coldcard Mk2, Mk3, Mk4, Mk5, Q |
| Introduced | 2021-03-01 (commit); 2021-03-17 (v4.0.0 release) |
| CVSS v3.1 (estimated) | 9.1 (Critical) — AV:N / AC:L / PR:N / UI:N / S:U / C:H / I:N / A:H |
| Attack prerequisites | No physical or logical access to the target device required |
| Detectability | Undetectable by the victim (no evidence of compromise) |
5.2 Scale of the entropy collapse
| Model | Design target | Effective entropy | Search space | Practical interpretation |
|---|---|---|---|---|
| Mk2 / Mk3 | 128 bits | ~40 bits | ~1.1×10^12 | Exhaustible in hours to days with a consumer GPU cluster |
| Mk4 / Mk5 / Q | 128 bits | ~72 bits | ~4.7×10^21 | Impractical with current consumer equipment; theoretically within range of nation-state or well-resourced attackers |
| Standard BIP-39 12-word seed | 128 bits | 128 bits | ~3.4×10^38 | Not exhaustible |
Mk4/Mk5/Q fared relatively better because their secure element mixed its own entropy into the PRNG state. However, per Coinkite's own technical backgrounder, most subsequent random values drawn on these models still came from the same compromised path after that initial mixing.
Some early reporting described the search space as "roughly 4 billion (2^32)." This figure appears to derive from Block's reference to a "32-bit reseed vulnerability" and should be distinguished from Coinkite's official 40-bit estimate. Either way, the conclusion is identical: it is an exhaustible search space.
5.3 Collateral effects beyond seed generation
The same compromised path was also used for functions other than seed generation. Block's public materials identify the following affected functions:
- Paper-wallet private key generation
- Seed XOR split-mask generation
- Device-cloning key generation
In other words, users who split and stored their seed via Seed XOR may also have had the split mask itself be predictable. This means the common assumption that "more advanced users were safer" holds only partially.
5.4 An unresolved criticism of the fail-open structure
Block characterized the Mk4/Q/Mk5 architecture as a "dangerous fail-open structure." Its point is that if an exception is caught early in the boot sequence, before the reseed routine runs, the device can operate with its exposed initial state and no additional entropy. Whether this scenario actually occurs in production remains a separate matter for evaluation, and is unresolved as of this report's writing.
This matters from a safe-design standpoint. A cryptographic random-number generator must be fail-closed. If it cannot obtain an entropy source, it must halt rather than return a value. A design that returns a value anyway, at reduced quality, conceals the very fact that it has failed.
6. Attack Chain Analysis — Offline Seed Reconstruction and On-Chain Sweeping
6.1 Step-by-step breakdown
| Step | Action | Observed basis |
|---|---|---|
| 1. Flaw identification | Analysis of open-source firmware and build configuration; search-space estimation | Public firmware repository |
| 2. Candidate seed enumeration | Reconstruction of candidate output streams by constraining UID, timer state, and prior RNG call history | Block's analysis |
| 3. Address derivation | Address generation across BIP-32/BIP-39/BIP-44, 49, 84 derivation paths | Standard specifications |
| 4. Balance matching | Cross-referenced against public blockchain data (the UTXO set) | Galaxy/Chainalysis analysis |
| 5. Prioritization | High-value wallets hit first, then expanded to smaller ones | ~$30 million in the first 10 minutes |
| 6. Automated sweeping | Identical hardcoded fee rate (30 sat/vB) across all transactions, no change outputs | Galaxy's analysis — consistent with automated tooling |
| 7. Fund retention | Held unspent across 7 attacker addresses (Waves 1–2) | On-chain observation |
6.2 Traffic fingerprint
Galaxy based its assessment of automated tooling on two indicators. First, every transaction used the same hardcoded fee rate (30 sat/vB). Legitimate wallet software adjusts fees dynamically based on mempool conditions. Second, there were no change outputs. This is a sweeping pattern that moves the entire balance to a single address.
This fingerprint provides a basis for future detection rules against similar attacks.
6.3 Differences between waves
| Wave | Timing | Scale | Characteristics |
|---|---|---|---|
| 1 | 07-30 01:10–01:51 UTC | 1,082.65 BTC / 1,196 addresses | High-value first, uniform pattern |
| 2 | Confirmed 08-01 | Cumulative 1,158.66 BTC / 2,673 addresses | Pattern similar to Wave 1; presumed same operator |
| 3 | Confirmed 08-02 | +207.73 BTC / 1,912 addresses | Targets smaller wallets; more complex, harder-to-trace pattern |
Galaxy stated that while each wave appears to be the work of a single operator, on-chain data alone cannot determine whether all three waves are the same actor. Wave 3's pattern shift leaves open two possibilities: improved tooling by the same actor, or a separate actor exploiting the same key space.
6.4 MITRE ATT&CK mapping
| Tactic | Technique | ID | Implementation in this incident |
|---|---|---|---|
| Reconnaissance | Gather Victim Host Information | T1592 | Analysis of device UID and timer characteristics |
| Reconnaissance | Search Open Technical Databases | T1596 | Querying the public blockchain UTXO set |
| Reconnaissance | Search Open Websites/Domains | T1593 | Analysis of the open-source firmware repository |
| Resource Development | Develop Capabilities: Malware | T1587.001 | Building automated sweeping tooling |
| Credential Access | Brute Force | T1110 | Exhaustive search of the collapsed seed space |
| Credential Access | Unsecured Credentials: Private Keys | T1552.004 | Deriving private keys from reconstructed seeds |
| Collection | Data from Information Repositories | T1213 | Collecting on-chain balance data |
| Impact | Financial Theft | T1657 | Sweeping bitcoin |
7. Impact Quantification — Three Waves of Attack
7.1 Scale of losses
| Item | Value |
|---|---|
| Cumulative amount stolen | 1,367.05 BTC |
| USD equivalent | ~$88.6 million |
| KRW equivalent (at ₩1,390/USD) | ~₩123.2 billion |
| Addresses affected | 4,585 |
| Duration of Wave 1 | 41 minutes |
| Single largest loss | ~$1.8 million |
| Publicly reported individual loss | 18.25 BTC (~CAD 1.6 million) |
| Funds recovered | 0 (entirety held, unmoved, in attacker addresses) |
| Delay between vendor awareness and disclosure | ~30 hours |
7.2 Victim profile
Per Galaxy's analysis, the stolen assets had an average dormancy of approximately 3.18 years. This suggests the victim population is concentrated among long-term individual holders, not institutions.
This profile carries three implications.
- Detection lag — many users had not opened their wallets in years, which substantially delayed awareness of the theft.
- An inverse correlation between security awareness and victimhood — a relatively security-conscious cohort, who distrusted exchanges and chose self-custody, ended up the victims instead.
- Irrecoverability — self-custodied personal assets carry neither deposit insurance nor an exchange's reserve/insurance backstop.
7.3 Ongoing risk
Galaxy warned that the attack is ongoing, and that every address generated from a vulnerable seed will eventually be emptied. That Wave 3 targeted smaller wallets means the attacker is lowering the economic threshold and working through the remaining pool of targets. The assumption "my wallet's balance is too small to be a priority" no longer holds.
8. Survivor Analysis — What Kept Wallets Safe
8.1 Conditions for survival
| Condition | Protection level | Basis |
|---|---|---|
| 50–98 independent dice rolls entered | Safe (the RNG flaw alone poses no risk) | Dice input alone contributes 128+ bits |
| 99+ independent dice rolls | Safe (contributes ~256 bits) | Same as above |
| Fewer than 50 dice rolls, or unable to recall | At risk — migration required | Per Coinkite's advisory |
| A strong, unique BIP-39 passphrase | Reduces immediate exposure, but does not solve the underlying problem | Creates a separate wallet unreachable from the seed words alone |
| Seed generated before the vulnerable firmware | Safe | Prior to v4.0.0 |
| Seed newly generated on fixed firmware | Safe | Device-generated entropy alone is now sufficient |
| Multi-sig (all keys generated on vulnerable devices) | At risk | Every key is affected by the same flaw |
| Multi-sig (some keys generated on other vendors' devices) | Conditionally safe | Depends on the threshold configuration |
The crux is that dice rolls were combined with device-generated entropy via hashing, and this user-supplied entropy was unaffected by the firmware flaw.
8.2 Implications — reassessing user-supplied entropy
The dice-roll feature had, until now, been treated as an "optional advanced feature for paranoid users." This incident shows it was the one line of defense that actually worked once vendor trust collapsed.
At the same time, as Casa's leadership has pointed out, expecting ordinary investors to roll dice to supplement their seed is unrealistic. This exposes the gap between usability and security in stark terms, and closing that gap through product design — not user education — is the industry's task.
The practical recommendation is clear. User-supplied entropy should shift from an optional feature to a default. At minimum, it is reasonable to make it a mandatory step when generating seeds intended for high-value custody.
9. Response and Migration — What the Patch Cannot Fix
9.1 Fixed firmware versions
| Model | Release track | Fixed version |
|---|---|---|
| Mk2 / Mk3 | Standard | v4.2.0 or later |
| Mk4 / Mk5 | Standard | v5.6.0 or later |
| Mk4 / Mk5 | Edge | v6.6.0X or later |
| Q | Standard | v1.5.0Q or later |
| Q | Edge | v6.6.0QX or later |
Note: Standard and Edge are separate tracks. Do not assume a build is fixed simply because its Edge version number is higher than the standard track's.
9.2 Limits of the patch
A firmware update does not change or restore existing seeds.
This single sentence is the whole story of this incident's remediation. The vulnerability lives not in the device, but in the number the device already drew. Accordingly, the following responses are all invalid:
| Invalid response | Why |
|---|---|
| Updating firmware but continuing to use the existing wallet | The seed itself remains vulnerable |
| Restoring the vulnerable seed into a different vendor's wallet | The attacker searches the seed space, not the device |
| Re-transcribing the vulnerable seed onto a new paper/metal backup | The seed value itself is the problem |
| Moving funds to a different address (derivation index) | Every address derived from the same seed is exposed |
| Splitting assets into smaller amounts | Wave 3 is actively targeting small amounts |
9.3 Correct migration procedure
- Confirm your model and release track, and install the corresponding fixed firmware first.
- Verify the fixed firmware installation directly from the version string shown on-screen.
- Generate a completely new seed. The fixed firmware's device-generated entropy alone is sufficient; dice rolls are optional.
- Back up the new seed and passphrase. Store the passphrase physically separate from the seed words.
- Power-cycle the device, then verify the wallet fingerprint and receive address on the device's own screen.
- Send a small test transaction first and confirm receipt.
- Transfer the remaining balance in full.
- Do not discard the old backup until migration is confirmed complete.
Coinkite and multiple research organizations consistently emphasize do not rush. Migration mistakes made under pressure — address typos, incorrect backups, skipped verification — have repeatedly been observed to cause losses larger than the hack itself.
9.4 Assessment of the vendor's response
| Action | Assessment |
|---|---|
| Fixed firmware shipped across all model tracks | Appropriate — rapid deployment |
| Full disposal of unshipped inventory | Appropriate — cuts off supply-chain contamination |
| Individual email notification to shipped customers | Appropriate but limited reach |
| ~30-hour delay before the first public advisory | Inadequate — the advisory came after Wave 1 had ended |
| Initial advisory classified Mk4/Q/Mk5 as "not affected," corrected on 8/1 | Inadequate — the initial scoping error distorted user decision-making |
| Explicit statement of unaffected products (TAPSIGNER/OPENDIME/SATSCARD) | Appropriate |
The 30-hour delay is the single point in this response that deserves the most criticism. That said, because the attack preceded the disclosure, even immediate disclosure likely could not have stopped Wave 1. The real problem is that many Wave 2 and Wave 3 victims lost their window to act during that delay.
10. Industry Implications — Re-Examining the Trust Model
10.1 Assumptions that collapsed
| Industry's implicit assumption | Refuted by this incident |
|---|---|
| A hardware RNG can be trusted | It can be disabled by a single build-configuration line, and the fact can be concealed |
| Open-source firmware is sufficiently audited | No one found this in five years of publicly available code |
| Physical isolation guarantees key safety | Isolation was perfect, and the assets still disappeared |
| Cold storage is safer than hot wallets | This comparison becomes meaningless in the face of a generation-stage flaw |
| Self-custody eliminates exchange risk | It merely trades exchange risk for vendor risk |
10.2 Structural lessons
First, the minimum unit of trust is not the device but the moment. A hardware wallet's security assessment should not ask "is this device safe?" but "was the moment this key was created safe?" This changes the very framing of asset-custody due diligence.
Second, a random-number generator must be fail-closed. A design that returns a low-quality value when it fails to secure an entropy source conceals the failure itself. This is precisely why NIST SP 800-90B's continuous health-test requirements exist.
Third, auditability does not mean an audit happened. Open source invites the collective illusion that "someone must have reviewed this." Whether a review actually took place is a separate fact, and anything unverified should be treated as not having happened.
Fourth, transparency is a double-edged sword. The public ledger is both the foundation for audit and verification, and the attacker's free reconnaissance infrastructure. Privacy techniques (CoinJoin, avoiding address reuse) had real defensive value in this incident.
Fifth, vendor concentration is a new single point of failure. When users in a decentralized system converge on a small number of hardware vendors, decentralization is preserved at the protocol layer while systemic risk accumulates at the key-generation layer. This incident is the first large-scale case of that risk materializing.
10.3 No issue was found at the protocol layer
One further point worth confirming: no flaw of any kind was found in the Bitcoin protocol, the secp256k1 curve, or the BIP-32/39 standards. The failure occurred entirely at the implementation layer, and specifically within one vendor's build configuration. Trezor, Ledger, and Block (Bitkey) have each confirmed their own products are unaffected.
This distinction matters for market communication. "Bitcoin was hacked" is inaccurate framing; the accurate framing is "a specific hardware-wallet manufacturer's key-generation implementation failed."
11. Korea Perspective — Regulatory Alignment and Recommendations for Domestic Exchanges
11.1 A blind spot in current domestic regulation
The Virtual Asset User Protection Act (effective July 19, 2024) requires virtual asset service providers (VASPs) to hold at least 80% of the economic value of users' virtual assets in cold wallets. This is an increase from the 70% threshold under the ISMS-certification requirements of the prior Act on Reporting and Using Specified Financial Transaction Information. Providers must calculate economic value and maintain this ratio on a monthly basis.
In February 2026, in a written response to the National Assembly's Political Affairs Committee, the Financial Services Commission (FSC) stated it would consider raising the cold-wallet custody ratio to around 100% as part of the subordinate regulations for the "Phase 2" Digital Asset Basic Act. It is also reportedly considering regulating digital-asset custody as a separate licensed business.
The problem is that this entire regulatory framework governs only the isolation premise.
| Regulatory metric | What it governs | Would it have defended against this incident? |
|---|---|---|
| 80% cold-wallet custody ratio | Where the asset is located | No |
| 100% cold-wallet custody ratio (under consideration) | Where the asset is located | No |
| ISMS certification | General management systems | Partially |
| Reserves/insurance (₩3 billion for KRW-market operators, ₩0.5 billion for others) | Post-hoc compensation | Response only after the fact |
| Key-generation entropy quality standards | Does not exist | — |
Even a 100% cold-wallet ratio would not have stopped this class of attack. A cold wallet generated from a vulnerable seed gets emptied while sitting 100% cold. In other words, the regulatory metric is not aligned with the actual risk.
11.2 Recommendations for domestic exchanges and VASPs
| Priority | Action | Detail |
|---|---|---|
| Immediate | Full audit of key-generation provenance | Inventory when, on what device/firmware version/HSM, every operational cold-wallet key was generated. If there is any history of using Coldcard-family devices, isolate and migrate immediately |
| Immediate | Check for consumer hardware wallets used on operational assets | Consumer hardware wallets are not designed for institutional custody. Confirm whether any were used even temporarily or for emergency purposes |
| 1 week | Verify entropy-source redundancy | Check whether HSMs rely on a single TRNG. Combine at least two independent sources via XOR so that if either fails, the other still preserves security |
| 1 week | Establish key-generation provenance record-keeping | Preserve signed logs of generation date/time, device identifier, firmware version, entropy source, and witnesses for every key. A prerequisite for post-hoc impact scoping |
| 2 weeks | Audit multi-sig/MPC configurations for heterogeneity | If every key in a threshold configuration was generated from the same vendor, same firmware, and same library, redundancy is meaningless. Distribute across vendors, architectures, and entropy sources |
| 2 weeks | Introduce cross-device entropy verification procedures | Incorporate statistical-independence verification of keys generated from two or more identical-model devices into the key-generation SOP |
| 1 month | Re-verify HSM certification requirements | Confirm the validity and scope of certifications such as FIPS 140-2/140-3 Level 3 or CC EAL4+, and whether RNG is included in the certified scope |
| 1 month | Firmware SBOM and change management | Obtain an SBOM for every component of the custody infrastructure. Mandate third-party security audits and regression testing before firmware updates |
| Quarterly | Establish a key-rotation policy | Eliminate indefinitely used keys. Regenerate with new entropy sources during periodic rotation |
| Ongoing | Strengthen on-chain anomalous-withdrawal detection rules | Alert on sweeping fingerprints such as hardcoded uniform fee rates, absence of change outputs, and full transfers from long-dormant addresses |
11.3 Policy recommendations for regulators
Extend regulation from storage location to the key lifecycle. The cold-wallet ratio is a necessary but not sufficient condition. The subordinate regulations under the Phase 2 Act should include integrity requirements covering the entire key generation, backup, rotation, and disposal lifecycle, independent of raising the storage ratio.
Codify RNG requirements when custody becomes a separately licensed business. In the custody-licensing framework the FSC is reportedly considering, entry requirements should be examined for explicitly mandating the use of certified random-number generators (compliant with NIST SP 800-90A/B/C or an equivalent standard).
Consider mandatory disclosure requirements for hardware-wallet vulnerabilities. A policy requiring domestic hardware-wallet vendors to notify users within a defined window (e.g., 24 hours) upon discovery of a critical vulnerability. This incident's 30-hour delay demonstrates the need.
Provide information disclosure for self-custody users. Self-custody carries neither deposit insurance nor reserve-based compensation. Exchanges should be required to disclose this fact, along with the existence of vendor risk, at the point of withdrawal.
Assess domestic distribution. There is currently no public data on how widely Coldcard has been distributed in Korea, or whether any domestic losses have occurred. A fact-finding effort by KISA and the Financial Security Institute, along with Korean-language advisories, is needed.
11.4 Characteristics specific to the Korean market
The Korean market is known for high exchange concentration centered on the five major KRW-market exchanges, and for relatively low self-custody rates driven by withdrawal restrictions to personal wallets under the Travel Rule. This reduces direct exposure to this particular incident, but leaves two risks:
- Key-generation risk concentrates within exchange custody infrastructure. Risk that would have remained an isolated individual incident if dispersed among individuals becomes systemic risk when concentrated at an exchange.
- As the corporate market opens and institutional custody expands, if custody providers' key-management standards are not established, an incident of the same type could recur at a far larger scale.
12. Recommendations for Bitcoin Investors
12.1 Immediate triage procedure for Coldcard owners
Q1. Was your wallet seed generated on a Coldcard?
No → Not affected (but check Q5)
Yes ↓
Q2. Was the seed generated after March 17, 2021 (firmware v4.0.0 release)?
No → Not affected
Don't know → Proceed as if affected
Yes ↓
Q3. Did you enter 50 or more independent, private dice rolls when generating the seed?
Yes (certain) → The RNG flaw alone does not pose a risk. Seed XOR users, however, see 12.3
No / can't remember ↓
Q4. Immediate migration required. Follow the procedure in Section 9.3.
Q5. Have you ever used the paper-wallet generation, Seed XOR splitting, or device-cloning features?
Yes → Those outputs may also have been predictable. A separate migration is required
A note for passphrase users: a strong, unique BIP-39 passphrase greatly reduces immediate exposure, but it does not restore a vulnerable seed. Coinkite recommends that passphrase users migrate as soon as practically possible as well.
12.2 Recommendations for general Bitcoin investors
| Recommendation | Rationale |
|---|---|
| Distribute across vendors | Single-vendor dependence is the systemic risk this incident demonstrated. If your holdings are large, spread them across devices from different manufacturers and architectures |
| Build multi-sig from heterogeneous sources | If all three keys in a 2-of-3 configuration came from the same model and firmware, redundancy provides zero benefit |
| Make user-supplied entropy a habit | Combine entropy the vendor does not control — dice rolls, coin flips — into your seed. At least 50 rolls |
| Use a passphrase, but store it separately | Keep seed words and passphrase in physically different locations |
| Avoid address reuse | Weakens the structure by which the public ledger becomes an attacker's reconnaissance asset |
| Check your balance periodically | This incident's victims averaged 3.18 years of dormancy. Establish a routine to check balances at least once a year |
| Subscribe to vendor security-advisory channels | The 30-hour disclosure delay was itself a problem, but users who never saw the advisory lost days more |
| Tier your custody approach to scale | Small amounts: prioritize convenience. Large amounts: multi-sig, heterogeneous vendors, user entropy |
| Understand the scope of self-custody responsibility | Self-custodied assets carry neither deposit insurance nor an exchange's reserve/insurance backstop |
12.3 What not to do
| Prohibited action | Reason |
|---|---|
| Treating "restoring a vulnerable seed into another wallet app/device" as having "moved" it | The seed value itself remains within the attacker's search space |
| Postponing migration because the amount is small | Wave 3 targeted wallets worth thousands of dollars |
| Making large transfers in a panic without verification | Migration mistakes have repeatedly caused losses larger than the hack itself |
| Providing your seed to a third party claiming to offer a "recovery service" | The period right after an incident is peak season for secondary phishing. Never give your seed to anyone, under any circumstances |
| Skipping firmware verification before generating a new seed | Generating a new seed on vulnerable firmware simply produces another vulnerable seed |
12.4 Response procedure for domestic (Korean) victims
- Preserve on-chain evidence — record the transaction ID(s) of the loss, the time (UTC), sending and receiving addresses, and amounts. Also capture screenshots from a block explorer.
- Report to law enforcement — the National Police Agency's Cyber Investigation Bureau or the cyber-investigation unit of the relevant local police station. International cooperation is often required, so the timing of the initial report matters.
- Report to on-chain analytics firms — Galaxy Research, Chainalysis, and others are building databases of attacker addresses. Providing victim-address information contributes to broader tracing efforts.
- Request exchange freezes — pre-register addresses with the compliance channels of major domestic and international exchanges in case the funds flow into an exchange. Because the funds currently remain unmoved, this measure has real practical value.
- Prepare tax documentation — the tax treatment of theft losses varies case by case, and records of asset movement plus proof of theft should be preserved. Specific determinations require consultation with a tax professional.
This section is general information, not legal advice. Legal responses to individual cases should be discussed with an attorney.
13. Detection, Response, and Prevention Checklist
13.1 Individual users
- Confirm the manufacturer, model, and firmware version of hardware wallets you own
- Confirm the generation time and generating device for each seed
- Confirm whether user-supplied entropy (e.g., dice rolls) was used
- If applicable: install fixed firmware → generate a new seed → send a small test → transfer full balance
- Separately check any Seed XOR, paper-wallet, or device-cloning outputs
- Set up block-explorer balance alerts
- Subscribe to vendor security-advisory channels
13.2 Exchanges and custody providers
- Inventory the generation provenance of every cold-wallet key
- Investigate any history of using consumer hardware wallets for operational assets
- Confirm whether HSM certification scope includes RNG
- Verify a multi-independent-entropy-source combination architecture
- Audit vendor heterogeneity across multi-sig/MPC configurations
- Incorporate cross-device entropy verification into the key-generation SOP
- Obtain a firmware SBOM and establish a third-party audit process prior to updates
- Deploy sweeping-fingerprint-based anomalous-withdrawal detection rules
- Establish and enforce a key-rotation policy
- Define a user-notification SLA for incidents (24 hours recommended)
13.3 Hardware-wallet manufacturers
- Redesign the RNG path to be fail-closed (halt operation if entropy acquisition fails)
- Add tests that verify the interaction between build configuration and library conditional compilation
- Incorporate cross-device seed-independence verification into the release gate
- Implement NIST SP 800-90B continuous health testing
- Consider converting user-supplied entropy input from optional to default
- Build an emergency vulnerability-notification system (multi-channel, given the limits of email reach)
- Provide an offline self-diagnosis tool for users
14. Conclusion
This incident shifts the focus of cryptocurrency security discourse from storage to generation.
Over the past decade, the industry concentrated its resources on improving "where you keep it" — from hot wallets to cold wallets, from single signatures to multi-sig, from self-custody to regulated custody. Korean regulation, too, has developed around the single metric of the cold-wallet custody ratio. That direction was correct in itself, and it genuinely prevented countless incidents.
But this incident revealed that all of that improvement rested on a single, unverified premise: that the key was made unguessable in the first place. That premise collapsed with a single build-configuration line, went unnoticed for five years, and as a result, $88.6 million disappeared from perfectly isolated devices.
Four points summarize this:
- Cold storage protects the key, but it does not guarantee the key's quality. Storage regulation must be complemented by generation regulation.
- A random-number generator must never fail silently. A fail-open RNG conceals the very fact of its failure, which is more dangerous than the failure itself.
- Auditability is not an audit. What has not been verified should be treated as not having happened.
- Decentralization must be evaluated layer by layer. Even when the protocol is decentralized, systemic risk persists if the key-generation layer is concentrated among a handful of vendors.
"Don't trust, verify" is one of Bitcoin's oldest principles. This incident shows that the principle must be applied not only to the protocol, but also to how one's own key was made — and most users have no means of verifying that. Providing that means is the next task for manufacturers and regulators alike.
15. References
- Coinkite. (2026). COLDCARD Security Advisory — Seed Generation. Coinkite Blog. https://blog.coinkite.com/coldcard-mk3-seed-generation-warning/
- Coinkite. (2026). Technical Deep Dive into the Entropy Issue. Coinkite Blog. https://blog.coinkite.com/entropy-technical-backgrounder/
- CoinDesk. (2026, August 1). How bitcoin cold wallets lost $70 million in an attack that never touched the devices. https://www.coindesk.com/tech/2026/08/01/how-bitcoin-cold-wallets-lost-usd70-million-in-an-attack-that-never-touched-the-devices
- CoinDesk. (2026, August 2). Bitcoin cold-wallet attack spreads to 4,500 addresses as losses near $89 million. https://www.coindesk.com/tech/2026/08/02/bitcoin-cold-wallet-attack-spreads-to-4-500-addresses-as-losses-near-usd89-million
- Decrypt. (2026). Coldcard Bitcoin Exploit Balloons to $88 Million as Attackers Keep Draining Wallets. https://decrypt.co/374817/coldcard-bitcoin-exploit-88-million-attackers-draining-wallets
- The Hacker News. (2026, August). Coldcard Hardware Wallet Flaw Linked to $70 Million Bitcoin Theft. https://thehackernews.com/2026/08/coldcard-hardware-wallet-flaw-linked-to.html
- BleepingComputer. (2026). COLDCARD wallet RNG flaw likely linked to $88 million Bitcoin theft. https://www.bleepingcomputer.com/news/security/coldcard-wallet-rng-flaw-likely-linked-to-88-million-bitcoin-theft/
- Tech Times. (2026, July 31). Coldcard Hardware Wallet Hacked via Firmware Bug That Bypassed RNG for Five Years. https://www.techtimes.com/articles/322392/20260731/coldcard-hardware-wallet-hacked-via-firmware-bug-that-bypassed-rng-five-years.htm
- crypto.news. (2026). A build error in Coldcard's firmware drained $38 million in bitcoin in 25 minutes. https://crypto.news/coldcard-firmware-bug-drains-38-million-bitcoin/
- Bitcoin Magazine. (2026). Coinkite Releases Fixed Firmware After Coldcard Bug; AI Likely Involved In The Breach. https://bitcoinmagazine.com/business/coinkite-releases-fixed-firmware-after-coldcard-bug-ai-likely-involved-in-the-hack
- The Crypto Times. (2026, August 1). Coldcard Hack Hits $75M After Alleged Second Attack Wave: Galaxy Research. https://www.cryptotimes.io/2026/08/01/coldcard-hack-hits-75m-after-alleged-second-attack-wave-galaxy-research/
- TechSpot. (2026). A Coldcard firmware flaw let hackers drain $70 million in Bitcoin in 41 minutes. https://www.techspot.com/news/113322-coldcard-firmware-flaw-hackers-drain-70-million-bitcoin.html
- PrivacyGuides. (2026, August 3). Nearly 1,400 Bitcoin Hacked from Coldcard Wallets. https://www.privacyguides.org/news/2026/08/03/nearly-1400-bitcoin-hacked-from-coldcard-wallets/
- 247wallst.com. (2026, August 1). Coldcard Hacked for $70M: How Do You Keep Bitcoin Safe if Cold Wallets Can Be Hacked? https://247wallst.com/investing/cryptocurrency/2026/08/01/coldcard-hacked-for-70m-how-do-you-keep-bitcoin-safe-if-cold-wallets-can-be-hacked/
- Financial Services Commission (Korea). (2023). Press Release on the Draft Enforcement Decree of the "Act on the Protection of Virtual Asset Users." https://www.fsc.go.kr/no010101/81214
- News1. (2026, February 20). "FSC Reviewing Raising Exchange Cold-Wallet Custody Ratio to 100%." https://www.news1.kr/finance/blockchain-fintech/6077484
- Decenter. (2026). "FSC: 'Reviewing a 100% Cold-Wallet Custody Ratio Under the Phase 2 Act.'" https://www.decenter.kr/article/20010694
- Etoday. (2026). "FSC: 'Digital Asset Basic Act as Swiftly as Possible' — Tied to Opening the Corporate Market." https://www.etoday.co.kr/news/view/2606627
- Blockmedia. (2025, January 16). "Digital Asset Cold-Wallet Custody Ratio Raised to 80%; Operational Approaches Vary by Exchange." https://www.blockmedia.co.kr/archives/843516
- TheElec. (2025, December 10). "Upbit Keeps Over 98% in Cold Wallets for Better Security." https://www.thelec.kr/news/articleView.html?idxno=45132
16. Appendix A — Impact Scope and Fixed-Firmware Cross-Reference Table
| Model | Affected firmware (per Coinkite advisory) | Effective entropy | Fixed version (Standard) | Fixed version (Edge) |
|---|---|---|---|---|
| Mk2 | v4.0.1 – v4.1.9 | ~40 bits | v4.2.0 or later | Not applicable |
| Mk3 | v4.0.1 – v4.1.9 | ~40 bits | v4.2.0 or later | Not applicable |
| Mk4 | All versions prior to the fix | ~72 bits | v5.6.0 or later | v6.6.0X or later |
| Mk5 | All versions prior to the fix | ~72 bits | v5.6.0 or later | v6.6.0X or later |
| Q | All versions prior to the fix | ~72 bits | v1.5.0Q or later | v6.6.0QX or later |
| TAPSIGNER | Not affected | — | — | — |
| OPENDIME | Not affected | — | — | — |
| SATSCARD | Not affected | — | — | — |
Note on inconsistent sourcing:for the Mk2/Mk3 affected range, Coinkite's advisory states v4.0.1–v4.1.9, while some early reporting states v4.0.0–v5.0.3. When in doubt, the safer approach is toassume you are affected and migrate.
17. Appendix B — Unconfirmed Items and Follow-Up Tracking Tasks
| Item | Current status | Need for tracking |
|---|---|---|
| Attacker identity and nationality | Unconfirmed. Galaxy has reported roughly 600 suspected addresses to law enforcement | High |
| Whether the three waves share a single actor | Unconfirmed. Waves 1–2 show a similar pattern; Wave 3 differs | Medium |
| Whether the attacker used AI | Vendor's inference; not confirmed | Medium |
| Whether the ~72-bit Mk4/Mk5/Q space has actually been attacked | Not observed to date | High |
| Whether Block's identified fail-open boot path actually occurs | Unresolved | High |
| Domestic (Korean) distribution volume and any domestic losses | No public data | High |
| Losses to paper wallets or Seed XOR outputs generated from vulnerable seeds | Not tallied | Medium |
| Final scale of losses | Ongoing, may expand | High |
| Whether regulators will introduce hardware-wallet certification schemes | Early-stage discussion | Medium |
This report is classified TLP:GREEN and may be shared within the community. Commercial use requires separate arrangement, and citations must credit the source. License: CC BY-NC-SA 4.0.
Disclaimer: This document is a threat-intelligence analysis based on open-source information (OSINT) and does not constitute investment or legal advice. Because the incident is ongoing, figures and the scope of impact may change.