Coldcard Flaws Expose Bitcoin Wallets After $38 Million Drain

Firmware flaw weakened Coldcard seed generation

Block’s Bitcoin engineering and security teams began investigating after receiving reports of remotely stolen Bitcoin from wallets unrelated to Block’s Bitkey product. The investigation linked the affected wallets to Coldcard devices and identified two separate weaknesses in the process used to generate wallet seeds.

Older Coldcard firmware contained the more serious flaw. On affected Mk2 and Mk3 devices, a firmware configuration disabled the built-in hardware random number generator. A supporting software library checked whether the RNG configuration existed but did not verify that the RNG was actually enabled.

Seed generation then fell back to a software method drawing from predictable device information, including the Coldcard serial number and internal clock registers or boot timing. Because those values were not cryptographically secure sources of randomness, an attacker could generate possible seeds until one produced a public address matching the intended target.

Attackers did not need to touch the affected Coldcard. A visible Bitcoin address, wallet descriptor or exported public key could provide enough information to test candidate seeds. Once a candidate generated the same address as the victim’s wallet, the attacker could derive the corresponding private key and authorize transactions.

The weakness was traced to a code commit dated March 1, 2021, first included in firmware version 4.0.0. Block’s technical analysis treated seeds generated on Mk2 or Mk3 firmware from 4.0.0 through 4.1.9 as a confirmed vulnerable path. Coinkite’s public warning told users that Mk3 seeds generated after version 4.0.1 could be at risk and extended its precautionary guidance through version 5.0.3, the final Mk3 release.

Coldcard Mk1 devices did not run the vulnerable code and were not affected by this specific failure. Mk2 and Mk3 devices using older firmware before the version 4 code path generated seeds through the hardware RNG, including the earlier 3.2.2 firmware line. Mk2 devices later upgraded into affected firmware could also have produced weak seeds.

Coinkite initially focused its warning on Mk3 devices. The company said: “If you generated a seed on a Mk3 after firmware 4.0.1, your funds may be at risk. Mk4, Q and Mk5 are not affected based on our early analysis.”

Later technical findings showed that Mk4, Q and Mk5 used a different entropy design but still mishandled randomness. Those devices attempted to supplement boot-time randomness with input from a secure element, yet retained only four bytes, or 32 bits, of the added entropy.

That contribution produced about 4.29 billion possible values. A separate assessment characterized the resulting strength on those devices as approximately 72 bits of entropy instead of the intended 128 bits. The mechanism differed from the highly predictable fallback affecting earlier models, but it still left materially fewer seed-generation paths than intended.

Tapsigner, Opendime and Satscard were not affected because they used different codebases. The vulnerable random source could also affect other Coldcard features that relied on it, including seed backups, paper-wallet generation and additional functions that created cryptographic secrets through the same implementation.

We’ve launched the all-new COIN360 Perp DEX, built for traders who move fast!

Trade 130+ assets with up to 100× leverage, enjoy instant order placement and low-slippage swaps, and earn USDC passive yield while climbing the leaderboard. Your trades deserve more than speed — they deserve mastery.

Firmware updates cannot repair existing seeds

The weakness was created when the seed phrase was generated. Installing newer firmware does not strengthen a seed that was already produced through the vulnerable process.

Importing the same mnemonic words into a different hardware wallet or software wallet also leaves the exposure intact. The seed itself remains weak, regardless of which device later stores it. Restoring the same backup on another manufacturer’s product therefore does not remove the attacker’s ability to test candidate keys.

Affected users must create a completely new seed using an unaffected and independently generated source of entropy. They must then create new receiving addresses and transfer their assets from the old wallet through an on-chain transaction.

Block privately disclosed its findings to Coinkite before publishing the technical details. Block released the findings before completing all testing because “active exploitation is underway.”

Max Guise, a Block engineer, urged users to move carefully but quickly. “Personally I recommend that anyone affected move funds as soon as they can safely do so,” Guise said.

Coinkite advised users without a separate BIP-39 passphrase to generate a new seed on an unaffected device, securely record and verify the new backup, confirm a receiving address and make a small test transaction before moving the remaining balance. Users were also advised to retain the old backup temporarily until the migration and test transfer had been successfully confirmed.

A separately chosen BIP-39 passphrase could materially reduce the risk because it adds another secret not contained in the weak mnemonic output. Coinkite said users who combined an independent passphrase with their PIN faced a very low chance of losing funds through the vulnerability, provided the passphrase had not been entered into a smartphone, computer or website.

A passphrase does not increase the randomness of the original mnemonic words. It creates a separate derived wallet that an attacker cannot access without also obtaining or guessing the passphrase. Its protection depends on the passphrase being independently chosen, sufficiently strong and kept away from insecure devices or phishing interfaces.

Peter Todd criticizes single-signature custody

The theft primarily affected single-signature wallets, where one seed or private key provides full spending authority. Once an attacker reconstructed an affected seed, no additional approval was required to transfer the Bitcoin.

Bitcoin developer Peter Todd said the incident exposed insufficient independent scrutiny and auditing of hardware-wallet code. Todd argued that security claims had relied too heavily on trusting embedded chips and vendor implementations without end-to-end deterministic testing on real hardware.

Todd demonstrated generating entropy physically with a deck of cards and referred to an earlier button-based random-number-generation proposal as an alternative to relying entirely on embedded hardware.

“It’s reasonable to add a hardware wallet in a multisig configuration. But with singlesig, it is probably better to stick with well-audited software on commodity hardware,” Todd wrote on July 31.

Todd’s recommendation did not rule out hardware-wallet use. He argued that hardware devices were more defensible as independent components within a multisignature arrangement than as the only security boundary protecting a single-signature wallet.

Multisignature setups are not automatically protected if every required key was generated through the same vulnerable Coldcard process. An attacker could theoretically reconstruct each weak seed until enough keys were compromised to satisfy the signing threshold.

Effective multisignature protection therefore depends on independently generated seeds and diverse devices, vendors, codebases or verifiable entropy methods. Existing weak seeds must be replaced rather than moved into a new multisignature configuration.

The Coldcard incident also showed that an air-gapped device can create remotely exploitable wallets. Air-gapping limits network exposure during signing, but it cannot protect funds when a wallet seed was predictable at creation.

A secure element can protect an existing key against physical extraction while still failing to ensure secure key generation if firmware truncates, bypasses or otherwise mishandles its entropy. The two Coldcard weaknesses affected seed creation rather than the physical storage of an already secure secret.

The incident placed greater attention on entropy generation, independent security audits, open-source firmware, reproducible builds, secure-element design, vulnerability disclosure, bug-bounty programs, firmware-update processes, recovery architecture, passphrase support and multisignature compatibility.

Open-source firmware can permit outside review, but published code alone does not establish that the same software is running on retail hardware. Reproducible builds allow researchers and users to compare released firmware binaries with published source code.

Coinkite’s initial statement that newer models were unaffected was expressly framed as an early assessment. Block’s later findings identified a separate weakness on those devices, making the sequence of disclosures distinct from the confirmed Mk2 and Mk3 fallback flaw and from the on-chain transactions still under investigation.