How Coldcard Was Hacked — and Why a Firmware Update Won’t Fix Your Seed

On July 30, 2026, a series of thefts began from Bitcoin wallets whose seeds had been created on vulnerable versions of Coldcard firmware. During the first major incident, 1,082.65 BTC was drained from 1,196 addresses in just 41 minutes. The attackers did not need physical access to a Coldcard, phishing, or a transaction signed by the owner.

The cause was a firmware integration bug: when creating a wallet, the code called a software pseudorandom generator from MicroPython instead of the STM32 hardware random number generator it was supposed to use. As a result, seeds created by the built-in generator on affected firmware versions could contain far less entropy than a properly generated seed should.

Below, we explain what happened to Coldcard, which firmware versions were affected, why simply updating the device does not fix an already generated seed, and how to move funds safely to a new wallet.

How Coldcard was compromised: what happened on July 30

The first major incident: 1,082.65 BTC in 41 minutes

Galaxy Research traced a group of similar transactions made on July 30 between 01:10:20 and 01:51:26 UTC. During that period, funds were moved out of 1,196 Bitcoin addresses, for a total of 1,082.65 BTC — roughly $70.2 million at the time.

The transactions shared several distinctive traits, including the same unusually high fee of 30 sat/vB and a similar structure. Those patterns helped researchers separate related transfers from normal network activity and estimate the scale of the attack.

Physical access to a Coldcard is not required for this type of attack. Candidate seeds can be tested offline, Bitcoin addresses can be derived from them, and those addresses can then be checked against addresses already visible on the blockchain.

The attacks continued

More clusters of thefts appeared after the first incident. On July 31, Galaxy identified another 76.16 BTC taken from 1,478 addresses. The next major incident, which ran from July 31 into August 1, added roughly 208 BTC from 1,912 addresses.

In its updates, Galaxy refers to the largest groups of related transactions as “waves,” while tracking smaller clusters and other attack traces separately. In other words, this was not simply four individual transfers, but a series of thefts linked to the same vulnerability.

According to Galaxy Research’s August 14 update, thefts totaling 1,778.84 BTC from more than 8,600 addresses — about $112.7 million had been confirmed with high confidence. Including medium-confidence incidents and a fourth large transaction cluster that had not yet been fully confirmed, the estimate could rise to 2,417.35 BTC — around $153 million.

Galaxy had not identified any new confirmed attacks after August 6, but that does not mean affected seeds became safe. Researchers explicitly warned that thefts could resume and advised owners of single-sig wallets whose seed was generated on an affected Coldcard to move funds to a fresh seed as soon as possible.

Researchers also concluded that the vulnerability was likely being exploited by more than one attacker. The final loss figure may still change as additional victims continue to report affected addresses.

If your funds have already been stolen

As of August 14, of at least 1,778 stolen BTC, around 1,531 BTC remained unmoved at addresses controlled by the attackers, while roughly 246 BTC had already been moved. Galaxy Research said it was in direct contact with 190 victims.

If you have already lost funds, do not throw away your Coldcard or destroy old backups. Coinkite specifically asks users to keep affected devices, because they may be useful in a future investigation or potential recovery process. Keep the affected addresses, transaction IDs (TXIDs), and any other wallet information that does not expose private keys.

What Coinkite did

Rodolfo Novak (NVK) publicly took responsibility for the firmware bug and apologized to affected users. Coinkite published an official security advisory, then released fixed firmware for every affected model and a separate step-by-step migration guide.

After confirming the issue, the company stopped shipments and destroyed remaining Coldcard inventory manufactured with vulnerable firmware, while its team began working directly with customers who needed help migrating. TAPSIGNER, OPENDIME, and SATSCARD were not affected by this specific bug because they use a different codebase.

The incident is not fully closed, however. On the current COLDCARD Security Status page, Coinkite states that a formal technical postmortem is still being prepared. The generation fix is already available, but the full explanation of how the bug passed earlier reviews and what processes the company will change has not yet been published.

What went wrong with Coldcard seed generation

How a seed should be generated

Every new Bitcoin wallet starts with a random number that should be practically impossible to predict. In BIP-39, a 12-word recovery phrase is based on 128 bits of initial entropy, while a 24-word phrase is based on 256 bits. The words shown to the user are simply a convenient way to record that secret.

That is why the length of a recovery phrase is only part of the story. What also matters is how unpredictable the underlying data was when the phrase was created. If the generator can produce far fewer possible outputs, an attacker no longer has to search the full theoretical BIP-39 space.

What went wrong

In March 2021, Coldcard changed part of the code responsible for obtaining random data during wallet creation. As Coinkite explains in its own technical backgrounder on the incident, an integration bug caused the call that was supposed to use the STM32 hardware generator to bind instead to MicroPython’s Yasmarang software generator.

The hardware random number generator did not “fail” while the device was running. The bug happened at firmware build time: the RNG call was linked to the wrong function implementation, while the build still completed without an error.

Block’s technical report traces the vulnerable path back to code introduced in v4.0.0 in March 2021. Coinkite’s current user guidance, however, defines the affected Mk2/Mk3 range as 4.0.1–4.1.9. That current matrix is the one users should follow when checking their wallet and planning a migration.

Why this made seeds guessable

Yasmarang is a deterministic software generator: if its initial state can be reproduced, it will produce the same sequence of values. In Coldcard, that state depended on the microcontroller identifier and timing-related device values. Those inputs can make a search harder, but they are not a proper cryptographic source of randomness.

On Mk2 and Mk3, no separate cryptographic source of randomness was added to those values. On Mk4, Mk5, and Q, data from secure elements was added during startup, but because of the way reseeding was implemented, only 32 bits of that value affected the software generator’s state. That dramatically reduced the number of possibilities an attacker had to test.

Coinkite estimates an effective search space of roughly 40 bits for Mk2/Mk3 and around 72 bits for Mk4, Mk5, and Q. That is far below what properly generated BIP-39 entropy should provide. Block separately cautions that practical attack difficulty depends on how much an attacker knows about a specific device and when the seed was generated. So these figures should not be read as a fixed number of attempts required for every wallet.

Once an attacker has a candidate seed, no interaction with the Coldcard is required. Bitcoin addresses can be derived from that seed and compared against public blockchain data. If the addresses match, the attacker has the correct key material and can sign a transaction independently.

Why a firmware update does not fix an existing seed

Fixed firmware changes how Coldcard generates a seed after the update. It cannot change a seed that was already created on vulnerable firmware. If that seed still controls funds, you need to create an entirely new wallet with a new seed and move the Bitcoin to the new wallet.

Restoring the same recovery words on a Trezor, BitBox, another Coldcard, or a software wallet does not solve the problem. You are restoring the same secret and the same set of keys that may already be easier to recover through brute force.

Who is affected by the Coldcard vulnerability

The key factor is not just the model you own, but the firmware version that was running when the specific seed was generated. Updating a Coldcard today is not enough if the wallet itself was created earlier on vulnerable firmware.

Which firmware versions are fixed

• Mk2 and Mk3: 4.2.0 or later.
• Mk4 and Mk5, Standard: 5.6.0 or later.
• Q, Standard: 1.5.0Q or later.
• Mk4 and Mk5, Edge: 6.6.0X or later.
• Q, Edge: 6.6.0QX or later.

Before generating a new seed, check the latest status on COLDCARD Security Status and download firmware only from the official Coldcard firmware page.

Standard and Edge are separate release branches. A 6.x version number may look newer than 5.6.0, but an older Edge release is not fixed just because its number is higher. Edge users need 6.6.0X or later on Mk4/Mk5, and 6.6.0QX or later on Q.

If you added dice rolls when generating the seed

The bug affected randomness generated by the device itself. Independent dice rolls entered through Add Dice Rolls provided a separate source of entropy. According to Coinkite’s current assessment:

• 50–98 honest, independent, private rolls: at least 128 bits of additional entropy;
• 99 or more: roughly 256 bits;
• fewer than 50, or you do not remember the exact number: do not rely on the dice-roll exception and migrate to a new seed.

Coinkite does not consider a seed vulnerable to this specific RNG issue if at least 50 honest, independent, private dice rolls were added when it was created and the roll sequence was never recorded or exposed. If you are not sure those conditions were met, the safer option is to create a new seed.

The problem affected more than wallet seeds

Block also found that the same flawed random-data path was used for more than seed generation. It also fed private keys for paper wallets, random Seed XOR masks, and a number of internal Coldcard keys and passwords. The level of risk differs between those features, but the underlying issue extended beyond the standard New Wallet flow.

What about multisig?

Multisig protects against this issue only if an attacker cannot recover enough keys to satisfy the signing threshold. In a 2-of-3 setup, for example, compromising one key is not enough. But if two or three seeds were independently generated on vulnerable Coldcards without additional entropy, an attacker could potentially recover enough keys to reach quorum.

That is why protection against a single vendor failure depends not simply on the number of devices, but on how independently the keys were generated and on the implementations used to create them.

What Coldcard owners should do now

If your seed was created on affected firmware and the independent-dice-roll exception does not apply, the main goal is to move your funds to a completely new seed. Follow the process carefully so you do not lose access during the migration itself.

1. Find out which firmware version was used when the seed was generated. If you cannot determine this reliably, take the cautious approach and treat the seed as potentially affected.
2. Verify your old backup and access to the wallet. Before resetting anything, make sure the recovery words are recorded correctly and that the wallet fingerprint (XFP) matches.
3. Install fixed firmware before generating a new seed. Confirm the version on the device itself and use only the official firmware file.
4. Create an entirely new seed. You can do this on a Coldcard with fixed firmware or on another trusted hardware wallet. Do not restore the old recovery words and treat that as a “new” wallet.
5. Record and verify the new backup. Check the XFP and receiving address directly on the hardware wallet screen.
6. Send a small test amount first. Make sure it arrives in the new wallet before moving the rest.
7. Do not destroy the old backup until migration is complete. Keep it until the entire balance has reached the new wallet and the transactions have confirmed.

Coinkite has published a separate official guide covering different migration scenarios: COLDCARD Migration Guide. If you use passphrase wallets, BIP-85 child wallets, multisig, or multiple accounts derived from the same affected seed, review the Special Cases section — every wallet that actually controls funds needs to be migrated.

If your Mk2 or Mk3 is your only device

You do not need to buy another Coldcard just to migrate. Coinkite confirms that Mk2 and Mk3 running firmware 4.2.0 or later can correctly generate a new seed.

If you do not have a second device, migration is still possible, but you will need to switch between the old and new wallets several times. Coinkite recommends the following order:

1. Verify the backup of the affected seed and record its XFP.
2. Install and confirm fixed firmware version 4.2.0 or later.
3. Once you are certain the old wallet can be restored, remove the seed from the device using Coldcard’s built-in function and create an entirely new seed.
4. Record and verify the new seed backup, its XFP, and the receiving address.
5. Restore the old seed, verify its XFP, and send a small test amount to the verified new address.
6. Restore the new seed, verify its XFP, and confirm that the test amount arrived.
7. Restore the old seed again, verify its XFP, and move the remaining balance.
8. Restore the new wallet and verify the full balance. Keep the old backup until every check is complete.

If the XFP or address does not match what you expect at any stage, do not send funds and do not destroy any backup. If you have a second device with fixed firmware, the official guide recommends using it so you do not have to keep restoring two seeds on the same Coldcard.

Passphrase: when it helps and when it does not

A BIP-39 passphrase is not the device PIN. It is used together with the recovery phrase and defines a separate wallet. The same words with a different passphrase produce a different set of keys and different addresses.

A strong, unique passphrase that has never been exposed creates an additional independent barrier. Coinkite explicitly says that it reduces the immediate risk, but does not fix an affected seed. A short, common, predictable, or reused passphrase can still be guessed alongside a candidate seed.

A passphrase does not fix an affected seed. Even if it is strong enough to provide meaningful protection, Coinkite still recommends moving to a new seed once you can do so safely. The passphrase itself must also be stored separately and accurately: losing it means losing access to that wallet.

How to reduce the risk of similar failures in the future

Additional independent entropy

With fixed Coldcard firmware, dice rolls are not required to eliminate this specific vulnerability: normal seed generation has already been corrected. But private dice rolls can still be added as an independent extra layer of protection. If you use this method, do not photograph or digitally record the roll sequence, and follow Coinkite’s official conditions.

Multisig with independently generated keys

The value of multisig is not simply having more keys, but having independent failure paths. The practical lesson from this incident is straightforward: if you use multisig to protect against a problem affecting one vendor, the keys need to be generated independently and the recovery process needs to be tested in advance. Otherwise, the added complexity can become a risk of its own.

How other manufacturers generate seeds

After the Coldcard incident, it is worth looking beyond whether a device simply has a “hardware RNG.” A better question is whether the system uses independent sources of randomness and what happens if one of them fails.

• Trezor: when creating a new wallet, combines entropy generated inside the device with external entropy supplied by the host. This reduces dependence on a single generator.
• Ledger: for a 24-word Secret Recovery Phrase, generates 256 random bits using a TRNG inside the Secure Element.
• BitBox02 and BitBox02 Nova: combine five entropy sources, including generators in the Secure Chip and microcontroller, a unique value created during manufacturing, host-provided entropy, and a cryptographic value tied to the device password.

Multiple sources do not guarantee security by themselves — what matters is how they are combined and implemented in code. But independent sources can prevent a single failure from automatically weakening the entire seed-generation process.

If this incident makes you switch to a hardware wallet from another manufacturer, the core rule remains the same: do not restore the old Coldcard recovery phrase on the new device as a way to “escape” the vulnerability. The new hardware wallet needs to generate a new seed, after which the funds should be transferred to new addresses with a normal Bitcoin transaction.

Check the current firmware version before creating a new wallet, not just the condition of the device when you buy it. A new device should also be verified and updated if necessary before you generate the seed that will actually hold funds.

Open-source code does not mean bug-free code

The vulnerable Coldcard code had been public for years, but simply having an open repository does not guarantee that every security-critical line has already been thoroughly reviewed. Open-source code makes independent audits and reproducible builds possible, but it is not a certificate that a project is free of bugs.

On the current COLDCARD Security Status page, Coinkite has collected results from targeted independent checks of the fix, including testing on a real Mk4, source-code review, and reproducible builds for some releases. The same page makes clear that these checks validate specific parts of the fix and are not a full independent audit of the entire firmware.

Did AI help the attackers?

It is not known exactly which tool was used to discover the vulnerability. However, Galaxy Research considers it highly likely that the attackers used AI models without restrictions on cyber tasks and cites Kimi K3 as an example of that class of model. Coinkite has also suggested that older versions of its public code may have been analyzed with AI.

That does not mean any specific model definitely found this particular bug. In its technical backgrounder, Coinkite says that just weeks before the incident, it had used one of the strongest available AI models to review the code — and that model did not find the issue. The right conclusion is therefore not “AI hacked Coldcard.” Rather, this incident shows that AI has become another tool for large-scale code analysis, without guaranteeing that a critical vulnerability will actually be found.

Does the Coldcard incident mean hardware wallets do not work?

No. Bitcoin itself was not broken, and signature verification was not bypassed. The network accepted correctly signed transactions. The failure happened earlier, when the secret used to sign those transactions was created.

A hardware wallet can isolate private keys from a phone or computer, but that isolation does not help if the key was created with insufficient randomness in the first place. That is why the Coldcard attackers did not need access to the device itself: they were trying to reconstruct the keys independently.

This incident shows that seed generation is just as much a part of the security model as protecting the keys after they are created. Firmware, entropy sources, backups, and the recovery process all work together as one system.

Conclusion

If your seed was generated on affected Coldcard firmware and you did not add at least 50 honest, independent, private dice rolls under Coinkite’s stated conditions, create a new seed and move your funds. If you cannot determine how the seed was generated, the official guide recommends migrating. Fixed firmware is required before generating the replacement wallet, but it cannot change an existing seed.

Do not restore the old recovery words on another device hoping to “regenerate” the keys — you will simply recreate the same wallet. Verify the new backup and receiving address on the hardware wallet screen, send a test transaction, and only then move the main balance.

If you still need the basics of recovery phrase storage, start with our guide “Top 5 ways to store a seed phrase safely” in the same blog.