The Coldcard hack explained: how an offline wallet could still be drained

Coldcard hack explained: what exactly happened?

From 30 July 2026 onwards, bitcoin was removed on a large scale from wallets that had been created with a Coldcard, a hardware wallet made by the Canadian company Coinkite, because the recovery phrases of those wallets turned out to be guessable. This was not a break-in on devices and not a case of stolen passwords. The keys had been weak from the moment they were created, for years, without anyone noticing.

The scale grew within days. Security.NL reported on 4 August 2026, on the basis of Galaxy Research, an amount of 88 million dollars from around 4,600 addresses. A day later, on 5 August 2026, Galaxy Research stated that across what the researchers themselves put at some 7,300 addresses, 1,596 bitcoin had been confirmed stolen, with presumably another 400 bitcoin unconfirmed, together around 128 million dollars. Research firm TRM Labs arrived in the same period at around 1,816 bitcoin spread over four waves, and called it the third largest crypto theft of 2026.

Those figures differ because they were established at different moments and with different confirmation methods. That is normal for an incident that is still running, and it is the reason why this article states the source and the date for each amount.

What is a recovery phrase, in plain language?

A recovery phrase is nothing other than a very large random number, written down as twelve or twenty-four words because words are easier to copy than digits. All your addresses and private keys are then derived from that number. Whoever has the number has the wallet, wherever that wallet is.

The security lies in the sheer number of possibilities. With twelve words it normally involves 128 bits of randomness, which amounts to more combinations than there are stars in the observable universe. All the computers in the world together would need longer than the age of the universe to work through them. The whole system rests on that: not on keeping a method secret, but on the simple fact that guessing is hopeless.

What went wrong technically?

In March 2021 the Coldcard received a firmware update with a new generator for random numbers, and because of a configuration error the hardware generator was not used but fell back on a software-based, predictable variant. Security.NL reported this on 6 August 2026 on the basis of researcher Amit Singh. Users saw nothing of it; the device simply showed a series of words as always.

The difference between those two generators is the whole story. A hardware generator reads out a genuine physical phenomenon, for example noise in a chip, and therefore delivers unpredictable outcomes. A software generator calculates a series according to a fixed formula; that series looks random but is not, because whoever knows the starting point knows the whole series. If that starting point is chosen from a small set, the entire space of outcomes is small.

According to TRM Labs the strength therefore dropped from 128 bits to, in some cases, 40 bits. That sounds like a difference of a factor of three and it is not: it is the difference between roughly 340 billion billion billion billion possibilities and roughly a thousand billion. That last number can be worked through completely with ordinary equipment within a foreseeable time.

An image that comes close: you buy a safe with a combination lock of four rings that each have a hundred positions, ten thousand times a hundred combinations. The rings turn smoothly and the lock looks solid. What you cannot see is that inside there is a small clamp because of which each ring only actually engages ten positions. The safe looks identical, feels identical and stops ten thousand times less.

Why did keeping it offline not help?

Keeping assets offline protects against someone coming to your key, and not against a key that was guessable from birth. A hardware wallet is designed never to let the private key leave the device, and that worked here too: nothing leaked. The problem was that the attacker did not need to steal the key, because he could calculate it.

One of those affected put it on X, quoted by Security.NL on 5 August 2026, with the observation that he had done everything right: never shared the recovery phrase, never had the devices online, everything in different safes, and that none of it made any difference because the hardware that created the recovery phrase contained a line of code from 2021. According to the report, in his case it concerned 1.6 million dollars.

This is why this incident is different from an ordinary wallet hack. With phishing or malware you can point afterwards to what went wrong in your own behaviour. Here there is nothing to point to.

Who is at risk and who is not?

The only people at risk are those who had their recovery phrase created on an affected Coldcard with the firmware in question; anyone who created the phrase elsewhere and only entered it on the device is not at risk along this route. That distinction is decisive and is frequently confused in reporting.

In practice it comes down to these questions:

1. Was the recovery phrase generated by the device itself at the time, or did you create it yourself and enter it?
2. When was the wallet created, and did that fall after the firmware update of March 2021?
3. Which model and which firmware version was involved at the moment of creation?
4. Has the phrase ever been reused for other wallets or derived accounts?
5. Is there still a balance on addresses derived from that phrase?

Which models and firmware versions are affected exactly?

Coinkite has by now set out the scope itself in an official advisory. For the Coldcard Mk2 and Mk3 it concerns firmware versions 4.0.1 from March 2021 up to and including 4.1.9. That is the most severe category. The Mk4, the Mk5 and the Coldcard Q are affected as well: recovery phrases created on those before the corrected firmware have, according to Coinkite, around 72 bits of entropy instead of the expected 128. Coinkite calls that impact less severe than with the Mk2 and Mk3, but still serious.

The corrected versions differ per model and per release track: 4.2.0 or higher for the Mk2 and Mk3, 5.6.0 or higher for the Mk4 and Mk5 in the standard track, 1.5.0Q or higher for the Q in the standard track, 6.6.0X or higher for the Mk4 and Mk5 in the Edge track, and 6.6.0QX or higher for the Q in the Edge track. Standard and Edge are separate tracks, so a higher version number in Edge does not automatically mean the correction is included.

Two nuances belong with this. Anyone who supplemented the recovery phrase at the time with at least fifty fair, independent and unrecorded dice rolls falls, according to Coinkite, outside the risk of this bug. And a strong, unique BIP-39 passphrase forms an extra barrier, although it does not repair the affected phrase.

A firmware update only corrects the creation of new recovery phrases and therefore does not repair an existing phrase. The other Coinkite products, the TAPSIGNER, the OPENDIME and the SATSCARD, are not affected because they run on a different code base.

Source: the official Coldcard Security Advisory by Coinkite of 30 July 2026, updated on 1 August 2026, and the status page with the corrected firmware versions per model. Both coldcard.com and blog.coinkite.com are domains of the manufacturer Coinkite itself; coldcard.com is the product site on which Coinkite publishes the firmware and the status notices. If you receive a message about your hardware wallet, always check whether you are on one of those addresses and do not follow links from emails or messages.

Important: never check this by entering your recovery phrase on a website or in a program you did not choose yourself. That is exactly what happened in the days after the incident, and we come to that shortly.

What did the manufacturer do?

Coinkite issued a security bulletin, called on users to update and migrate to a newly created recovery phrase, and destroyed the remaining stock of wallets with the vulnerable firmware. Security.NL reported that last point on 4 August 2026. According to the company, destruction was the only option, because the wallets have security locks which mean that a device once programmed can no longer be upgraded before a user takes it into use, with the risk that someone misses the update.

In the same report Coinkite states that until that moment it had not been aware of the problem and that it concerns a complex series of subtle errors. The company suggests that the source code is public and that the bug was probably found in that code with the help of AI, and says it carried out such an analysis itself without finding it. At the time of writing no plans have been announced to compensate those affected, and an extensive evaluation has been announced but has not yet appeared.

What happened to those affected afterwards?

Within a week, owners of a Coldcard became the target of a phishing campaign in which they were asked to carry out a hardware audit, where the link in reality installed a program for remote access. Security.NL reported this on 6 August 2026 on the basis of security firm Proofpoint; it concerned the program ScreenConnect, with which attackers could then reach the system.

This pattern is predictable and repeats itself after every major incident. Anyone who has just heard that their device had a problem is receptive to a message offering to check that problem. A request to install something via a link or to enter your recovery phrase somewhere is, in this context, almost always the second attack.

Paucitas never asks for your recovery phrase or private key of its own accord. If you need help reading out or recovering your wallet, we guide you through that entirely, without needing to see that data ourselves. In addition: services that promise guaranteed recovery or restitution in exchange for payment show the pattern of a recovery scam.

What can you do yourself and when is that not enough?

Doing it yourself here means: first establish whether you are at risk, and only then act. Check whether the recovery phrase was created by the device and when that was, update the firmware through the manufacturer’s official channels and not through a link in an email, and if in doubt move your assets to a wallet with a new recovery phrase created elsewhere.

Do not move in a rush without knowing where you are moving to. In the days after an incident many assets are moved to destinations that looked fine at that moment, and that creates a second problem. Take the time to create and store the new phrase safely.

Doing it yourself is not enough as soon as something has actually been taken. It is then no longer about security but about recording: what exactly is gone, when, and where to. See also investigation after a hacked wallet and what can be recovered after phishing or a hack.

What can an investigation after this kind of incident do and not do?

An investigation records the route and the scale and can point to the place where the assets reached a service provider, but cannot recover assets and cannot identify anyone. The limits here are the same as in any other file:

• Paucitas does not independently establish who is behind a crypto address. What is recorded is which service provider or party the assets went to, so that this information can be followed up through the channels intended for it.
• Paucitas does not hold assets itself and does not carry out transactions on behalf of clients.
• Paucitas makes no commitment about the outcome of an investigation.
• Where mixers or privacy-oriented networks are used, the chain cannot always be followed in full. In that case it is stated explicitly up to which point the route can be established.
• Paucitas gives no tax or legal advice.
• The report states explicitly to what extent there is still access to the wallet involved, because that determines what can factually be established.

What does make an investigation into this incident special is that those affected share a common cause. That means establishing the moment of creation and the firmware used becomes part of the file, alongside the usual reconstruction of the transaction route up to the cash-out point.

Paucitas uses no automated analysis software, in any role. The investigation is done manually on the basis of publicly accessible block explorers. Every transaction and every transaction hash is verified one by one before it is included in a report.

What does the report contain?

The report follows a fixed structure: reason and description of the assignment, questions to be answered, scope, starting points, data supplied, sources consulted, working method in outline, verification and quality assurance, reservations and limitations, findings per element, chronological overview, analysis and coherence, conclusion, statement of independence, and appendices. Not every report contains all elements and the structure is tailored to the purpose of the report.

In an incident like this the chronological overview is decisive, because the times of the withdrawals show which wave an address fell into. That is relevant both for a police report and for any collective step towards the manufacturer, on which your lawyer advises.

What is the first step if you think you have been hit?

Start with an establishment of the facts before you report anything anywhere. Paucitas reconstructs which addresses belong to your wallet, when something left them and where those assets ended up, and records that with dates, amounts and transaction hashes. Without that finding there is nothing on which to base a notification or a police report; with it there is an overview a third party can work with.

You can always contact us for that, even if the incident was months or years ago. The sooner you start, the more there is still to preserve outside the chain, but a case does not expire and the chain itself forgets nothing. If it follows from that finding that filing a report is the logical next step, we refer you on to the Dutch police, because only along that route can coercive powers be deployed towards an exchange where assets arrived. If you want to keep an eye on an address after something has happened, address monitoring after an incident can follow on from that.

How long does such an investigation take and what does it cost?

An investigation by Paucitas takes, depending on the size of the file and the urgency, between one working day and two weeks. An urgent report can be delivered within one working day and in exceptional cases the same day. A regular investigation is usually ready within three working days. For files with many transactions, several wallets or missing history, the lead time rises to around two weeks. A surcharge applies to urgent assignments.

Depending on the nature and size of the case, Paucitas works with a fixed rate or an hourly rate. Which form applies is determined in advance and confirmed in writing. No investigation is started before the costs have been discussed and agreed.

Data can be supplied digitally or at the office. For each case a list is provided setting out which data is needed. Where necessary, Paucitas guides the collection and delivery of it.

What is the broader lesson from this incident?

The broader lesson is that the weakest point of a wallet is not the storing but the creating, and that this moment happens once and cannot be repaired by paying closer attention later. Anyone who kept their assets carefully offline for years did nothing wrong; the fault lay in a component nobody could inspect.

For those who want to act on that: the only structural answer is not to leave the randomness entirely to a device, for example by creating a recovery phrase partly or wholly outside the device. That is not advice we write down here as a recommendation, because the trade-off between that risk and the risks of improvising yourself depends on your situation and level of knowledge. What is established is that the assumption that offline equals safe has been refuted by this incident.

If you have been hit and want to know what can factually be established in your case, we will look at it with you during a free intake. You will also hear honestly when an investigation will produce little in your situation.

Sources consulted: Security.NL, 4 August 2026 (destruction of stock, Galaxy Research figures); Security.NL, 5 August 2026 (revised Galaxy Research amount, statement by an affected owner); Security.NL, 6 August 2026 (technical cause according to Amit Singh, phishing campaign according to Proofpoint); TRM Labs, August 2026 (bit strength and number of waves).