Coldcard Key Exposure

There is an ongoing exploit of an error in the firmware of Coldcard devices that resulted in highly insecure wallets being generated by default. If you have used a Coldcard, you must carefully evaluate whether your bitcoin is at risk and act accordingly. If you are at risk, or are unsure, you should migrate your funds immediately following the guidance below.

Which wallets are insecure / have exposed keys?

Wallets derived from a seed generated on a Coldcard running firmware version 4.0.1 or later (excluding the emergency patch released on 2026/07/30) which were setup using the default initialisation steps are insecure wallets. An exposed key is defined as one which is associated with these insecure wallets.

Whether the device was updated following the insecure wallet generation is irrelevant. Updating does not repair an existing seed.

Furthermore, users are reporting that their devices have been bricked by applying the latest 2026/07/30 firmware updates. If at all possible do not update the firmware on the device and simply sweep the funds and put the device into storage.

Protection via a passphrase

A secure BIP39 passphrase is unique and generated using genuine randomness rather than chosen by a person. For example, 12 independently and randomly selected words would be extremely difficult to guess. Common phrases, quotations, personal information, reused passwords, predictable word combinations are not secure passphrases. You should not enter your passphrase anywhere online to evaluate it's security, because such sites could harvest your passphrase in order to steal your funds.

If your passphrase is not truly randomly selected, you should treat your wallet as insecure and migrate your finds.

Protection via dice rolls

If you entered 50+ dice rolls when creating the wallet then you did not follow the default setup, and you have a more secure wallet than the insecure wallets which used the default setup procedure - your key is not exposed by this bug.

If you can't remember how many dice rolls you performed you should treat your wallet as insecure and migrate your funds.

Migration

If you have an insecure wallet / exposed keys you should migrate to a new wallet urgently.

Single Sig

If you have a single sig Coldcard wallet with an exposed key your funds may have been stolen already - check your wallet to confirm. If they have not they should be migrated to a new wallet immediately. Broadcasting the transaction publicly at a sufficiently high fee rate for next block confirmation is likely the best option to minimise the chance of theft. You can check the current fee rates at mempool.space

MultiSig

If you have a multisig wallet in which exposed keys reach the signing threshold (2-of-3 or M-of-N where M are coldcards) your funds are at high risk and should be migrated urgently.

There is nuance with how to proceed:

¹ “Policy not disclosed” assumes that the complete witness script, descriptor, cosigner xpubs, coordinator data, PSBT records and equivalent wallet metadata have not leaked through another channel.

Submission-route notes

Public broadcast: Propagates quickly across the Bitcoin network but exposes the transaction to public-mempool monitoring. An attacker able to spend the same inputs may submit a higher-fee conflicting transaction.

Private submission: Can avoid revealing a previously concealed witness script through the public mempool, but requires trusting the submission service and participating miners not to leak or relay the transaction. Confirmation may take longer and is not guaranteed.

Judgement Call:
The spending information is already available to an attacker, so private submission no longer provides secrecy. A high fee public broadcast will give faster confirmation, but exposes you to attackers who are only monitoring the public mempool.

Private mempools
You can directly submit to a miner running a private mempool. MARA Slipstream is a popular option that does not require registration. Any private mempool provider must be trusted not to leak or relay the transaction before confirmation, and none guarantees confirmation. Confirmation may take hours because the transaction must wait for MARA, which controls approximately 5% of the network hashrate, to find a block.

Note that there is a privacy tradeoff when submitting a private transaction, you reveal your IP address to the recipient server. Given the sensitive nature of this data in combination with potentially high value bitcoin transactions we have suggested to Mara to setup a tor hidden service to allow broadcasts which don't reveal this information.

Slipstream | MARA Holdings, Inc.

MARA Holdings, Inc.

Outofband: direct-to-miner broadcast

Submit signed PSBTs and raw transactions straight to MARA Slipstream, so they are mined without ever entering the public mempool. Everything runs in your browser.

Outofband

If the UTXO’s witness script or equivalent wallet-policy information is already known (for example, because its descriptor, cosigner xpubs, coordinator data or an earlier spend has revealed it) an attacker can steal those funds without waiting for you to broadcast anything.

There are currently no reported instances of attackers having stolen funds by replacing unconfirmed multisignature spends. For these UTXOs, it may therefore be preferable to broadcast publicly using a fee rate targeting confirmation in the next block rather than leave them exposed for hours.

Notes:

• If every cosigner key is exposed (for example, a 2-of-3 wallet created using three default-setup Coldcards) a spend reveals the cosigner public keys contained in that witness script. An attacker may compare those public keys against keys derived from candidate affected seeds. If enough seeds are recovered and the wallet’s descriptor and derivation structure can be determined, the attacker may be able to derive the remaining addresses belonging to the same standard descriptor wallet. If this describes your setup and you have ever spent from the wallet, treat the entire wallet as already public and consider broadcasting the migration transaction publicly using a high fee rate.
• Paper wallets generated using the Coldcard on affected firmware should be treated as affected.
• Similarly, keys transferred using the Key Teleport feature should be treated as affected.

Where to Migrate to

You should do your own research - there are a number of good signing hardware options available. When used in a multi-vendor multi-sig a very robust setup can be achieved, provided sound operational and backup practices are followed.

Users may consider a self-managed wallet using multiple independently implemented signing devices, or a collaborative custody provider. Multisignature and timelocked recovery policies introduce additional backup, descriptor and operational requirements, so users should understand and test the complete recovery process before transferring substantial funds.

Examples of such tools include Sparrow Wallet, Liana Wallet, Anchor Watch & Unchained. Do your own research and ensure you are on the legitimate websites.

Plausible Attack Progression and Reported Incidents

One plausible attacker progression is to prioritize candidates that combine low search cost, easily identifiable funded outputs and high expected value.

They may then progress to the harder to steal coins (requiring more cost and more complex tooling) only once they have exhausted their search or detect that they have competition within a search space.

Phase 1 - Offline key-space enumeration against single-signature wallets

Description:

The attacker derives low entropy wallets, scans for spendable UTXOs, constructs theft transactions and broadcasts them. This phase is fully automated and high throughput.

Likely theft order:

1.1 - single sig Mk2/3 no passphrase, no dice throws
1.2 - single sig Mk2/3 with weak passphrase or small number of dice rolls
1.3 - single sig Mk4 / Mk5 / Q no passphrase
1.4 - single sig Mk4 / Mk5 / Q with weak passphrase or small number of dice rolls

Real world data:

• July 30, ~01:10 UTC: The first wave of thefts from single sig Mk3 no passphrase [source]
• Aug 1, 2026. A reported theft from a single-signature Mk4 with no passphrase [source]
• Aug 2, 2026, ~04:00 UTC A reported theft from a single-signature Mk3 with a weak two-word passphrase. [source]

Phase 2 - Multisig via address/key reuse

Description:

The attacker scans for unspent outputs which are known multisigs which have addresses that have previously been spent from. They then search the redeem script / witness script for matches against indexed weak public keys. For each output they find where the threshold can be met by the compromised keys, they construct a transaction stealing the funds.

Likely theft order:

2.1 - multisig with threshold met by compromised Mk2 / Mk3 keys with address reuse
2.2 - multisig with threshold met by compromised Mk2 / Mk3 / Mk4 / Mk5 / Q devices with address reuse

Real world data:

None reported yet. Blockchain and mempool scanning is ongoing in an effort to identify any such spends

Phase 3 - Multisig via live mempool scanning

Description:

Similar to phase 2, except instead of searching for outputs stored in reused addresses they monitor the public mempool. For each multisig spend they search the redeem script / witness script for matches against indexed weak public keys. For each output they find where the threshold can be met by the compromised keys, they construct a transaction stealing the funds. If they detect a spend they must react quickly (seconds to minutes) to construct and broadcast a replacement theft transaction.

Likely theft order:

3.1 - multisig with threshold met by compromised Mk2 / Mk3 / Mk4 / Mk5 / Q devices with public mempool RBF

Real world data:

There have been no reported instances of this type of theft. There have been many migrations performed using Slipstream, which could not have been stolen in this manner.