What happened
On July 30, 2026, attackers began systematically draining Bitcoin from Coldcard hardware wallets. Blockchain analytics firm Galaxy Research tracked the first wave: 1,082.65 BTC, worth about 70.2 million dollars at the time, pulled from 1,196 addresses in just 41 minutes. Two more waves followed on August 1 and August 2, pushing the total to 1,367.05 BTC, roughly 88.6 million dollars, taken from 4,585 addresses. Galaxy reported around 600 attacker-controlled addresses to federal investigators as the sweep continued into a possible fourth wave.
The root cause traces back five years. Coinkite's Coldcard is marketed as an air-gapped, security-hardened wallet for holders who don't trust software wallets or exchanges with private keys. That reputation made the wallet a common choice for high-net-worth individuals and crypto-native businesses managing self-custodied treasury. The scale and precision of the drain, hitting thousands of addresses within hours across multiple waves, indicates the attackers had mapped vulnerable addresses well before executing the theft.
The bug: a random number generator that wasn't random
The flaw shipped in firmware version 4.0.1 in March 2021 and persisted through 4.1.9 on Coldcard's Mk2 and Mk3 models, with related entropy weaknesses affecting Mk4, Q, and Mk5 as well. A production configuration flag, MICROPY_HW_ENABLE_RNG, was set to zero, which meant the device's key generation library never bound to the STM32 chip's true hardware random number generator. Instead it silently fell back to MicroPython's Yasmarang generator, seeded only from the chip's unique ID and timer registers, with no ongoing entropy collection afterward.
The practical effect: Mk3 devices generated seeds with an estimated 40 bits of effective entropy, and Mk4/Mk5/Q devices around 72 bits, against the 128 bits a secure 12-word BIP-39 seed is supposed to provide. Block's security team summarized the exploit path bluntly: an attacker who can determine or sufficiently constrain the device UID, timer state, and prior RNG call history can reproduce candidate output streams offline. That is a small enough search space to brute-force with modern compute, especially once attackers built tooling to correlate deterministic seeds with on-chain addresses.
Coinkite's response and its limits
Coinkite released updated firmware for all affected models on July 31, 2026, a day after the first sweep. But a firmware patch only prevents new weak seeds from being generated going forward. It does nothing to protect funds already sitting behind a seed the deterministic generator produced years ago. Coinkite's own guidance to customers was explicit: funds controlled by a seed generated on Mk2 or Mk3 version 4.0.1 or later are at risk unless that seed was created with at least 50 fair, independent, private dice rolls, or the wallet is protected by a strong, unique BIP-39 passphrase.
That guidance puts the burden back on the user to know exactly how their seed was originally generated years ago, a detail most holders never tracked. Galaxy Research's advisory was more direct: move Coldcard single-sig funds to a new wallet immediately, full stop. For any organization holding treasury reserves or customer custodial funds on affected hardware, the only safe remediation is a full migration to a freshly generated seed on patched firmware, not a firmware update applied in place.
Why this matters beyond crypto holders
This is a textbook entropy failure, the same class of bug that has periodically undermined SSH keys, TLS certificates, and now hardware crypto wallets: a hardware RNG that exists on paper but never actually gets wired into production code. It shipped in a device explicitly sold on the premise of superior security assurances, went unnoticed for five years across multiple firmware releases, and was only caught after attackers had already reverse-engineered it well enough to drain nearly 90 million dollars.
For CISOs and treasury teams outside the crypto-native world, the lesson generalizes. Any hardware security module, HSM, or key management appliance that claims to use a hardware entropy source deserves an actual verification, not a vendor spec sheet. Firmware supply chains for security-critical devices need the same scrutiny as software supply chains: SBOMs, reproducible builds, and independent audits of cryptographic primitives, not just penetration tests of the attack surface around them.
What enterprise security teams should do now
If your organization or any vendor in your custody chain uses Coldcard devices for treasury, signing keys, or customer fund custody, inventory every unit and check firmware version and seed generation date immediately. Any seed generated between March 2021 and the July 31, 2026 patch on an unpatched device should be treated as compromised and migrated, not merely updated in place. Do not wait for a confirmed loss before acting. Given the campaign is still running in waves, the window between deciding to migrate and actually moving funds is the exact window an attacker who has already mapped your address is waiting for, so treat this as an incident response action with a deadline measured in hours, not a routine maintenance ticket to schedule for next sprint.
More broadly, this is a good trigger to review how your organization vets hardware security devices before they enter production. Ask vendors for evidence, not assurances, that hardware entropy sources are actually used in the code path, and build a periodic re-verification into your vendor risk process rather than a one-time approval at procurement. A flaw like this can sit dormant in shipped firmware for years before anyone notices, and by the time it surfaces, the funds are already gone.
