COLDCARD hardware wallets (Coinkite Inc.) ship a dedicated hardware true-random-number generator, but a firmware regression merged in early 2021 caused builds to silently bind to MicroPython's software PRNG fallback instead. The root cause is a three-layer configuration defect: the production board config (`stm32/COLDCARD_MK4/mpconfigboard.h`, lines 77-78) defines `MICROPY_HW_ENABLE_RNG` as `0` because Coinkite supplies its own hardware-RNG wrapper; the libngu cryptographic library's availability guard in `switck/libngu/ngu/random.c` (lines 22-30) uses `#ifndef MICROPY_HW_ENABLE_RNG`, which verifies only that the macro is *defined*, not that it is *enabled* (non-zero) — so the guard passes even with the macro set to zero, and the build links against MicroPython's `rng_get()` fallback in `Coldcard/micropython/ports/stm32/rng.c` (lines 64-98) instead of the real hardware RNG. That fallback (an implementation of the Yasmarang PRNG) is initialized only from `pad = UID_low32 ^ SysTick->VAL`, `n = RTC->TR`, and `d = RTC->SSR` — the device's fixed 96-bit UID (only the low 32 bits used), a free-running down-counter (at most ~80,000 distinct values on Mk2/Mk3, ~120,000 on current devices), and RTC time registers correlated with (and potentially static relative to) boot time — none of which are cryptographically secure entropy sources, and the resulting stream is fully deterministic for a known device and timing state.

The regression first shipped in COLDCARD Mk2/Mk3 firmware v4.0.0 (commit merged 2021-03-17, tracing to a libngu macro-check change from 2021-01-28 and a seed-generation migration to libngu via commit `b18723dd` on 2021-03-01, which replaced `rng_bytes(seed)` with `seed = random.bytes(32)` routed through `ngu.random.bytes`), leaving firmware versions 4.0.1 through 4.1.9 affected until the fix in 4.2.0. Independent root-cause analysis (Block Inc. Engineering) computed the resulting search space precisely: for Mk2/Mk3 v4 firmware with a known UID and call history the keyspace collapses to 2^0 (fully deterministic); with only timers unknown it ranges from ~2^16.29 (SysTick alone) up to ~2^40.7 (all timers). Later COLDCARD Mk4, Q, and Mk5 models added a secure-element-based reseed step (`shared/mk4.py`, commit `01cb43f7`) intended to mitigate the flaw — it draws 32 bytes from one secure element via `callgate.read_rng(1)` and 8 bytes from a second via `callgate.read_rng(2)`, SHA256d-hashes them, then calls `ngu.random.reseed(n)` with only the first 4 bytes of the digest unpacked as a 32-bit integer, discarding the rest and never resetting the other Yasmarang state words. This caps the mitigated devices' effective security at ≤2^32 possible outputs (~2^31 average enumeration to a successful guess) rather than restoring 128-bit security; Coinkite's own advisory (which separately cites commit `621e808712464688584fdffad9eba132cc7c27cd` in `shared/seed.py`, lines 276-332, describing how COLDCARD hashes the device-generated seed together with any user-supplied dice rolls) states this yields ~72 bits of entropy for Mk4/Q/Mk5 versus the expected 128, and that seeds lacking 50+ independent physical dice rolls (contributing ≥128 bits) remain under-entropied regardless of firmware version.

Exploitation began July 30, 2026 — roughly a day before Coinkite's public disclosure — when an attacker drained 1,082.65-1,083 BTC (~$70.2M) from 1,196 addresses in a 41-minute window (Wave 1), using single-input sweep transactions with no change output and a uniform, well-above-market transaction fee (a hardcoded ~30 sat/vByte, a 30-75x overpay versus the ~0.4-1.0 sat/vByte prevailing median), consistent with automated/scripted tooling that offline-reconstructs candidate seeds from the constrained keyspace, derives corresponding Bitcoin addresses, and checks them against the public blockchain. Chainalysis's timing analysis of Wave 1 found the attacker extracted roughly $30M within the first ten minutes alone and $1.8M from a single victim, indicating the wallets had likely been identified and studied by value in advance rather than drained in random order. Coinkite shipped emergency patched firmware within roughly two days of the first wave and destroyed its remaining device stock awaiting shipment that still carried the affected firmware. Galaxy Research subsequently identified two further waves on August 1: a wave targeting materially smaller balances (~208 BTC across ~1,912 addresses, averaging ~0.1 BTC/victim, running Friday midday through Saturday morning UTC) that batched an average of six victims per sweep transaction (versus Wave 1's one-at-a-time sweeps), scanned only the default derivation path per seed (rather than testing multiple branches), shifted output style from plain single-key outputs to Pay-to-Witness-Script-Hash (P2WSH, which supports multisig/timelock spending conditions), and — unlike Waves 1-2, which consolidated stolen funds into a handful of shared collector addresses — routed each victim's coins to its own unique destination address, likely to reduce on-chain clustering and complicate downstream tracing. Cumulative losses across all three waves reached approximately 1,367 BTC (~$88.6M) from between 4,385 and 4,585 addresses depending on source and reporting cutoff. Galaxy Research reported roughly 600 suspected attacker-controlled addresses to federal investigators, compliance firms, and cross-industry cyber investigators, crediting victims who voluntarily shared addresses/txids for helping establish the on-chain attacker pattern; it assesses Waves 1-2 likely share an operator based on transaction-pattern similarity (identical fee, no-change, shared-collector signature) but cannot confirm the same is true of Wave 3, while noting the same sweep signature 'looks the same as if a coin owner chose to move coins,' complicating attribution.

Security researchers have drawn a direct parallel to Ledger Donjon's 2022 discovery that the Trust Wallet browser extension generated wallets fully recoverable from their public address alone, requiring roughly five months to patch before public disclosure — both incidents illustrate that a biased or deterministic RNG produces output that is statistically indistinguishable from true randomness and passes casual inspection ('a bad RNG is silent'), so discovery depends on independent or adversarial audit rather than routine testing. Commentary accompanying disclosure also observed that, industry-wide, LLM-assisted vulnerability research is compressing the general window between a patch's disclosure and its weaponization, a contextual risk factor for firmware/cryptographic defects of this class even though the confirmed exploitation of this specific flaw began before Coinkite's public disclosure.

No CVE has been assigned to this issue by any source reviewed. Coinkite's remediation guidance: update to patched firmware (4.2.0+ for Mk2/Mk3; 5.6.0+ standard / 6.6.0X+ Edge for Mk4/Mk5; 1.5.0Q+ standard / 6.6.0QX+ Edge for Q), then generate and migrate to an entirely new seed — firmware updates do not retroactively repair a seed already generated on vulnerable firmware. Seeds supplemented with 50+ fair, independent, private dice rolls, or protected by a strong unique BIP-39 passphrase, are treated as lower-risk, though full seed replacement remains the recommended path. Coinkite's TAPSIGNER, OPENDIME, and SATSCARD products use separate codebases and are not affected. The vulnerable `ngu.random` code path also fed paper-wallet private keys, ephemeral ECDH keys (device cloning, USB encryption, Key Teleport, Web2FA), seed XOR masks, and Secure Notes passwords, all of which inherit the same weakness; functions that instead call `ckcc.rng_bytes` reach the hardware RNG directly and are unaffected.