Coldcard owners are being told to treat their existing seed phrases as compromised and to move their Bitcoin to fresh wallets generated under fixed firmware, as new research links a major theft campaign to a critical flaw in the devices’ random-number generation.
Dogecoin ecosystem contributor Mishaboar sounded the alarm on August 1, urging anyone who has ever relied on a Coldcard device to immediately migrate their funds to a new wallet with a brand‑new seed. He emphasized that users must not recycle their old Coldcard seed phrases and must not type recovery words into any internet‑connected computer, even during an emergency migration. His warning is broader than the official position of Coldcard manufacturer Coinkite, which has limited its formal advisory to specific models and firmware versions.
The heightened concern follows a fresh on-chain analysis from Galaxy Research, which estimates that at least three coordinated attack waves have siphoned off 1,367.05 BTC – about 88.6 million dollars at the time of the report – from 4,585 Bitcoin addresses. Galaxy describes this number as the “observed size” of the theft, stressing that it reflects only what can be seen and clustered on-chain and has not yet been formally confirmed by Coinkite, law enforcement, or all affected holders.
According to Galaxy’s breakdown, the first major sweep on July 30 was both fast and focused. In roughly 41 minutes, attackers drained 1,082.65 BTC from 1,196 addresses, a pattern that suggested they were going after higher‑value wallets first. By the third identified wave, the strategy appeared to change: about 208 BTC disappeared from 1,912 addresses, with an average balance just over 0.1 BTC per wallet. That shift points to a progression from larger hoards toward smaller, retail‑sized holdings, as the attackers apparently tried to clean out remaining vulnerable seeds.
Each wave, Galaxy said, showed internal consistency pointing to a single operator: similar transaction structuring, timing, and patterns inside each cluster of thefts. However, they could not determine whether the same actor controlled all three waves or whether multiple groups exploited the same underlying vulnerability. The third wave in particular stood out: it funneled funds to a different set of destination addresses, combined many victims into single transactions, and only checked the default derivation path, unlike earlier sweeps that appear to have searched more paths on the seed.
Researchers also cautioned that their heuristics only capture what matches known patterns. Another attacker could have used the same weakness in Coldcard’s seed generation without copying the specific fee levels, address formats, or batching styles seen so far. That means the true scale of losses could be larger than the current 1,367 BTC estimate, and some compromised wallets may not yet be publicly recognized as part of the same incident.
Coinkite’s own advisory pins the vulnerability on a regression in the firmware’s randomness when creating new wallet seeds. The issue affects seeds generated on Coldcard Mk2 and Mk3 devices running firmware versions 4.0.1 through 4.1.9. It also covers seeds created on Mk4 and Mk5 units before standard firmware version 5.6.0 or Edge firmware version 6.6.0X. For the newer Coldcard Q line, the corrected releases are standard version 1.5.0Q and Edge version 6.6.0QX. Coldcard Mk1 units fall outside the problem range identified by investigators.
Coinkite has clarified that several of its other products do not share this vulnerability. TAPSIGNER, OPENDIME, and SATSCARD use separate codebases and are not affected by the specific random-number regression. As a result, there is currently no technical evidence that every device the company has ever produced is unsafe, despite some generalized warnings circulating among users.
The flaw itself was traced by Block’s Bitcoin engineering and security team to how the firmware handled entropy – the randomness required to create unpredictable cryptographic keys. Instead of consistently relying on the STM32 hardware random-number generator as intended, vulnerable software paths sometimes fell back to a deterministic MicroPython routine when generating wallet secrets. On Mk2 and Mk3 devices with the v4 firmware series, this fallback path added no true cryptographic entropy at all. Later models received only a partial salvage: a limited reseeding from the secure element, which improved but did not fully correct the issue.
Because the MicroPython fallback produced predictable output under certain conditions, attackers who understood the bug could systematically recreate or narrow down the seeds generated during the affected period. Once a bad actor can guess or brute-force a seed, every private key derived from it – and thus all associated Bitcoin – becomes accessible.
Block stressed that its technical write‑up reflects its current understanding and does not replace exhaustive testing of every single device combination in the field. Coinkite, for its part, has said its investigation remains ongoing and has committed to releasing a detailed technical report to document the exact scope and behavior of the bug.
The company has now shipped fixed firmware for all impacted hardware lines and release tracks. These updates correct the entropy handling for any new wallet seeds created after installation. However, the nature of randomness means that no software update can retroactively fix a seed phrase that was already generated with insufficient entropy. Any seed born under the flawed firmware remains weak forever, and simply importing that phrase into a different hardware model or a software wallet carries the vulnerability along with it.
For that reason, the core recommendation is unambiguous: affected users must generate an entirely new seed under corrected firmware and move their funds to addresses derived from that new seed. Coinkite instructs users to first upgrade to the appropriate fixed firmware version for their device. Only then should they create a replacement wallet, write down the new backup phrase carefully, and verify that it has been recorded correctly.
The migration itself should be done cautiously. Coinkite suggests checking the first receiving address directly on the device’s screen, then sending a small test transaction from the old wallet to the new one. Users should wait until this test payment is confirmed and visible in the new wallet before transferring the remaining balance. This step acts as a sanity check against mis‑typed addresses, setup errors, or misunderstandings in the migration process.
Users are also advised not to destroy or discard their old backups until the entire migration has been verified. If something goes wrong during the move – for example, if a typo in the new backup phrase is discovered later – having the old seed available may be the only path to recovery, even if that seed is unsafe for long‑term storage. Once the funds have been fully cleared from the old wallet and the new seed has been thoroughly tested, the outdated backup should no longer be used.
Mishaboar, echoing long‑standing best practices, has urged holders never to type their seed phrases into a computer during this rush to safety. Entering recovery words on keyboards that have been exposed to the internet risks interception by malware, keyloggers, or remote attackers. Instead, seeds should be kept strictly offline, with backups stored in separate, secure physical locations – for instance, two or more geographically distinct, private spots – to reduce the risk of theft, fire, or other local disasters.
Coinkite has also highlighted a narrow exception that may protect some users who took extra steps when creating their seeds. Certain Coldcard devices allow owners to contribute additional randomness by rolling physical dice. According to the company, users who added at least 50 independent, fair, privately rolled dice results directly into the seed creation process likely injected enough external entropy to offset the firmware flaw. For those rare cases, the seed may be secure even if it was generated on a vulnerable firmware version. However, correctly remembering and verifying that this process was followed is crucial; vague memories are not a sound basis for trusting an old wallet.
This incident has reignited a wider debate over self‑custody and hardware wallet trust models. Many Bitcoiners favor hardware devices precisely because they isolate private keys from everyday, internet‑connected systems. Yet the Coldcard bug illustrates that hardware security is only as strong as the firmware and entropy sources behind it. A single regression in random-number handling, unnoticed for a period of time, can undermine the safety of thousands of wallets that were otherwise stored and used correctly.
For users, the most practical takeaway is that self‑custody requires ongoing attention, not a one‑time setup. Owners should keep track of firmware announcements from their chosen wallet providers and be willing to perform migrations when critical vulnerabilities surface. Maintaining a clear, documented backup procedure – including how to verify new receive addresses and test transactions – can transform a stressful emergency like this into a controlled, step‑by‑step operation.
In concrete terms, Coldcard users who may be affected can follow a straightforward plan:
1. Identify your device model and current firmware version.
2. If it falls within the ranges listed by Coinkite, treat any seeds generated on that firmware as unsafe by default.
3. Upgrade the device to the latest fixed firmware for your model.
4. Create a brand‑new wallet and seed on the updated firmware.
5. Carefully record the new seed phrase (and any additional password, if you use a 25th/13th word) offline.
6. Confirm a receiving address on the device screen, then send a small test amount from the old wallet.
7. After confirmation, move the remaining funds.
8. Only once the migration is fully validated should the old wallet be considered retired.
Some advanced users may choose to use passphrases – sometimes referred to as a 25th or 13th word – to add another layer of protection to their new seeds. When used correctly and memorized or backed up securely, a strong passphrase can make brute‑forcing a seed vastly more difficult, even if a future vulnerability impacts part of the seed generation process.
The Coldcard episode will likely shape how hardware wallet makers design and test their products going forward. Independent audits of random-number generation, deterministic fallback behavior, and integration paths between microcontrollers and secure elements may become more routine. End users, meanwhile, may increasingly demand transparency around how their devices create and protect cryptographic secrets.
For now, the priority remains urgent but clear: anyone whose Coldcard seeds were created under the affected firmware conditions should assume those seeds are at risk and migrate to fresh wallets generated after installing fixed firmware. Handling that process calmly, offline, and with careful backups can limit the damage from a serious vulnerability and restore the security guarantees that self‑custody is meant to provide.