Coldcard Hardware Wallet Bug Enabled Large-Scale Bitcoin Theft Without Breaching Secure Elements

Coldcard's dual secure elements were not physically compromised. A technical review published by BIT on 7 August 2026 says the theft wave that began on 30 July 2026 exploited a weakness one layer earlier: the software path that generated the wallet seed before it was ever handed off to the secure element. In other words, the chips can be excellent at resisting extraction and still end up protecting a seed that was weak at creation. How the weakness formed Coldcard is made by Canadian firm Coinkite and uses two tamper-resistant secure elements—a Microchip ATECC608 and a Maxim DS28C36B—designed to withstand lab-grade extraction attempts, according to BIT. The issue was not the storage chips but the randomness used when generating seeds. Block's analysis, cited by The Hacker News on 1 August 2026, says a production configuration set a macro, MICROPY_HW_ENABLE_RNG, to zero because Coinkite provides its own hardware RNG wrapper. A supporting library, libngu, then checked only whether the macro existed, not whether it was enabled. That mistake bound the firmware to MicroPython's fallback RNG, "Yasmarang." CoinDesk's 31 July 2026 report describes the same root cause: a build setting disabled the hardware RNG and a supporting check tested for the presence of the setting rather than whether it was active. Block traced the change to a commit dated 1 March 2021, per CoinDesk. Reports differ on how the fallback generator was seeded, though not on the practical outcome. The Hacker News (citing Block) says Yasmarang was initialized from the device's unique ID and timer registers and did not gather fresh entropy afterward. CoinDesk describes similar inputs as the chip serial number and clock registers, calling them non-secret. BIT's 7 August 2026 account describes two Yasmarang instances XORed together, with one seeded from public, hardcoded constants. The variance reflects outside teams reconstructing the same incident rather than a line-by-line public walkthrough by Coinkite. How weak the seeds may have been Coinkite's own estimate, cited by The Hacker News, BIT and crypto.news, is that seeds generated under the bug had about 40 bits of effective entropy on Mk2 and Mk3 devices, and about 72 bits on Mk4, Mk5 and Q—well below a 128-bit design target for a standard BIP39 seed. Block, per The Hacker News, declined to provide a single brute-force figure, offering conditional ceilings and warning that the higher estimate should not be treated as true ~73-bit cryptographic security. No public report cited here has published a benchmark for brute-forcing these seeds, and none has reconstructed a specific victim seed and matched it to a drained address, according to The Hacker News. What secure elements do—and don't do BIT draws a clear boundary: the secure element "does not verify that the seed was generated with sufficient randomness". It protects the seed after it exists. It cannot assess whether the seed was strong when it arrived. That distinction matters in wallet comparisons. BIT says Coldcard's two-chip design raises the bar for physical extraction because an attacker would need to defeat two independently sourced secure elements plus the main processor. BIT notes Ledger and Trezor use a single secure element each. A Spark Money comparison (undated in the version reviewed) says Ledger uses STMicroelectronics secure elements certified to Common Criteria EAL5+ or EAL6+ depending on model, while Trezor Safe 3 and Safe 5 use Infineon's OPTIGA Trust M. Spark Money also says Trezor's secure-element documentation is public for independent auditing, while Ledger's secure-element firmware remains closed under an NDA with STMicroelectronics (even though Ledger's application-layer software is largely open). Coldcard publishes its firmware source in full, according to both Spark Money and BIT. Even so, openness did not prevent a March 2021 configuration error from persisting for more than five years. An auditable codebase is not the same as a codebase that is continuously audited closely enough to catch a subtle guard error—checking whether a setting is defined rather than what it is set to. Why loss estimates vary across outlets Figures reported for the same event differ largely because they reflect different time cutoffs and address-mapping scope. CoinDesk (published and updated 31 July 2026) reported about 594 BTC (roughly $38 million) swept from around 500 single-signature wallets between 01:31 and 01:56 UTC. crypto.news (1 August 2026) reported the same 594 BTC and roughly $38 million but placed the sweep between 02:14 and 02:39 UTC. The timestamp discrepancy cannot be resolved from the evidence cited. The Hacker News (1 August 2026) cited Galaxy Research mapping 1,196 addresses drained in 41 minutes on 30 July, totaling 1,082.65 BTC (about $70.2 million). The same article was later updated to report two additional waves, lifting the observed total to 1,367.05 BTC (about $88.6 million) across 4,585 addresses. BIT (7 August 2026) reported a cumulative total through 3 August 2026 of about 1,816 BTC (over $116 million) across more than 5,200 addresses, calling it the largest hardware wallet exploit on record. The smaller figures describe the initial sweep; the larger figures reflect cumulative totals as Galaxy Research continued mapping suspected addresses over subsequent days. Galaxy, per The Hacker News, cautioned that its findings rely on on-chain pattern analysis and that it has not computationally confirmed every flagged address was generated with weak Coldcard entropy. Galaxy also said activity was ongoing as of its update and that it had reported roughly 600 suspected attacker-controlled addresses to investigators, meaning totals could still change. What remains unsettled in public reporting No source cited provides a single definitive final loss number. The 594 BTC, 1,082.65 BTC, 1,367.05 BTC and 1,816 BTC figures should be read as measurements taken at different dates and scopes, not competing final answers. crypto.news reported that Coinkite suggested an attacker may have used AI to find the flaw and that Coinkite's own AI review weeks earlier found nothing serious, calling the claim "plausible but unverified." No independent confirmation is cited in the reviewed evidence. The Hacker News also notes that no public report has reconstructed a stolen seed and matched it to a drained address. Galaxy's wave attribution identifies transaction behavior rather than a confirmed cause, and Galaxy declined to treat Wave 3 as linked to Waves 1 and 2. On scope of vulnerable versions, Coinkite's advisory names Mk3 firmware 4.0.1 through 4.1.9 as vulnerable and does not name Mk2. Block's separate analysis (per The Hacker News) places both Mk2 and Mk3 versions 4.0.0 through 4.1.9 on the vulnerable path. The evidence cited here does not resolve which range is definitive. No equivalent external technical review of Ledger's or Trezor's seed-generation code is cited here. crypto.news reported on 1 August 2026 that Block, Trezor and Ledger said their products were unaffected by this specific flaw, which addresses this bug rather than serving as a broad audit of their randomness implementations. Sources referenced in the brief: BIT (7 August 2026), CoinDesk (31 July 2026), The Hacker News (1 August 2026), crypto.news (1 August 2026), Block (as cited).