Why it matters: A hardware wallet is supposed to solve one problem: keep your Bitcoin keys somewhere no attacker can reach them. This week showed what happens when the flaw sits inside the wallet itself. A firmware bug that's been shipping in Coldcard devices since 2021 let an attacker guess supposedly random seed phrases from the outside, no physical access, no phishing, no malware required, and drain funds from thousands of addresses. The running total is already past $88 million, and it's still climbing.
A flaw in Coldcard's firmware has put the spotlight on a basic part of wallet security: how the device generates its seed in the first place. The issue came into focus after an attacker drained 1,196 Bitcoin addresses on July 30 in a 41-minute stretch, taking 1,082.65 BTC worth about $70.2 million at the time.
Galaxy Research tied the sweep to Coldcard, the Bitcoin-only hardware wallet line made by Coinkite, and said the pattern matched a firmware problem rather than a random event. Two more waves have surfaced since, and Galaxy's running total now stands at 1,367.05 BTC, worth about $88.6 million, across 4,585 addresses. The firm describes that as a preliminary observed figure that could still climb as it traces more on-chain activity.
The problem goes back to a March 2021 firmware integration error. Instead of using the STM32 hardware random number generator, affected devices fell back to a deterministic software pseudorandom number generator when creating seeds. That matters because seed generation is supposed to produce output that cannot be guessed or reconstructed.
– Galaxy Research (@glxyresearch) July 31, 2026
In plain terms: a wallet's seed is the master code, usually a string of 12 or 24 words, that can recreate every address and private key tied to it. That code has to come from a process nobody could predict or reverse-engineer, which is why devices lean on a dedicated randomness chip instead of ordinary software. When that swap happens quietly in reverse, the numbers still look random on screen, but they aren't, and that gap is what an attacker can exploit.
Block said an attacker who can pin down the device UID, timer state, and earlier random-number calls can reproduce candidate output streams without touching the wallet itself. Those candidate seeds can then be tested by deriving addresses and comparing them with public blockchain data. In other words, the weakness isn't in the blockchain, but in how the wallet device formed the starting point for key generation.
Put simply, the attacker never had to steal or even see the physical wallet. If you can work out roughly how a device's internal clock and serial number behaved the moment it powered on, you can recreate the same "random" number it generated on an ordinary computer, then just check whether that guess unlocks a real, funded address.
The bug traces back to a config mismatch in Coldcard's production code. The firmware defined a hardware RNG setting, but the library that handled it checked whether the setting existed rather than whether it was actually enabled. That sent the build into MicroPython's Yasmarang fallback, which starts from fixed device data and doesn't gather fresh entropy after initialization.
In practice, this was a coding oversight rather than a deliberate shortcut. The software was supposed to check whether the hardware randomness generator was switched on, but it only checked whether that setting existed in the code at all, which was true either way. So every device quietly fell back to the weaker method, a backup meant only for rare edge cases, without anyone noticing it had become the default.
Coinkite says the effective entropy is about 40 bits on the Mk3 and about 72 bits on the Mk4, Mk5, and Q. That's well below the 128 bits expected from a standard 12-word BIP-39 seed.
To translate the bit counts: think of entropy as the size of a combination lock. A 40-bit lock has around a trillion possible combinations, small enough for ordinary hardware to work through in hours. 72 bits is a much bigger lock, out of reach for a hobbyist but not for a well-funded attacker. A proper 128-bit lock, by contrast, would take far longer than the universe has existed to crack by brute force, even at billions of guesses a second.
Coinkite released emergency firmware on July 31 for all affected models and release tracks. That update, however, doesn't fix seeds that were already created. The company is telling users with exposed seeds to generate a new one on patched firmware and move their coins. Restoring an old seed on a new device or updated firmware doesn't remove the weakness.
Which devices are exposed depends on the firmware running when the seed was created. Block places Mk2 and Mk3 versions 4.0.0 through 4.1.9 on the vulnerable path, while Coinkite lists Mk3 versions 4.0.1 through 4.1.9 and says the issue was fixed in 4.2.0. For newer models, Mk4 and Mk5 are affected before 5.6.0, the Q before 1.5.0Q, and Edge builds before the later edge-specific fixes.
Coinkite says seeds built with at least 50 fair, independent, private dice rolls aren't exposed to this bug alone. Users who aren't sure how their seed was made should migrate anyway, the company says. A strong BIP-39 passphrase creates a separate wallet, but Coinkite still recommends replacing the seed. Multisig only helps if the quorum isn't made up entirely of affected devices. Tapsigner, Opendime, and Satscard use different codebases and aren't affected.
– Zynx (@ZynxBTC) August 1, 2026
No one has named the attacker. Galaxy said it found no other Bitcoin transactions in the previous 30 days with the same 30 sat/vB, no-change pattern, but it also warned that the signature identifies the operator, not necessarily the theft. A sweep, the firm said, can look the same as a legitimate move by the owner.
A second wave on July 31 drained another 76.16 BTC from 1,478 addresses, and a third, identified August 1, took 207.73 BTC from 1,912 more – bringing the three-wave total to the current 1,367.05 BTC. Galaxy said the first two waves shared the same transaction fingerprint, but the third used a different output pattern, which the firm said could mean the original attacker changed tools, or that a second party is now exploiting the same flaw.
The failure has landed hardest on exactly the users who took the most care to avoid it. Jonathan Goodman, who says he lost roughly $1.6 million in the exploit, described keeping his Coldcard in a safety deposit box that had never touched the internet, textbook practice for cold storage. "I did everything right," he wrote in a post that circulated widely on X.
Coldcard's user base has traditionally skewed toward people who went out of their way to learn self-custody rather than casual holders, which has fed a broader sense among affected users that no publicized best practice fully protects against a flaw built into the hardware itself.
– Jonathan Goodman (@itscoachgoodman) August 1, 2026
This situation has fed a wider debate on Bitcoin forums over what self-custody can realistically promise. If a five-year-old firmware bug could sit undetected in a well-regarded device, some holders are asking what basis there is for treating other hardware wallets as safe simply because they haven't been caught yet.
Others have pointed to Coinkite's own acknowledgment that AI tools may have helped surface the flaw as a sign the gap between a bug shipping and someone finding it is likely to keep shrinking.
The incident comes soon after Coinspect's "Ill Bloom" research in early July, which described a separate weak-PRNG flaw in older software wallets and linked it to more than $5 million in losses across several blockchains since May. The two disclosures point to the same lesson: when randomness is weak, the rest of the cryptography can be perfectly sound and still fail.
