Coldcard Seed Flaw Drained 70 Million in Bitcoin From 1,196 Wallets

An attacker emptied 1,196 Bitcoin wallets in 41 minutes and took 70 million dollars. The owners did nothing wrong. Their hardware wallet had been quietly building guessable keys since 2021. 🧐

A hardware wallet sells one promise. You keep your key on a small device that never connects to the internet, and there is nothing for an attacker to reach. The device can sit powered off in a safe on another continent. The promise was that the key could not be guessed. People read it as a promise that the key could not be reached. This theft went after the first promise, and it never touched a single device.

The device is a Coldcard, a bitcoin hardware wallet made by a Canadian company called Coinkite. To understand what broke, you need one idea about how any of these wallets work.

When you create a wallet, the device picks one enormous number. That number is the seed. The addresses you receive to, and the private keys that spend your coins, come out of that seed through fixed, public rules that are open to run. The only thing protecting your coins is that the seed cannot be guessed, drawn from a dedicated hardware chip whose job is to produce true randomness.

On the affected firmware, it was not drawn from that chip.

In March 2021 the wallet’s code was reorganized. Seed generation moved from the function that read the hardware randomness chip to a new library path. That path quietly fell through to a software substitute, a small predictable generator that ships inside MicroPython, instead of the hardware source it was meant to use. Nothing crashed, and nothing warned. The wallet kept making seeds, and they looked random.

The reason it slipped past review sits in a single line. The library had a safety guard meant to stop the build if the hardware randomness was not switched on:

1
2
3
4
5
6

  extern uint32_t rng_get(void);
  #define CHIP_TRNG_32() rng_get()

  #ifndef MICROPY_HW_ENABLE_RNG
  #error "get a HW TRNG plz"
  #endif

That guard uses #ifndef, which only checks whether the setting exists, not whether it is turned on. The board configuration did define the setting, and set it to zero, because the wallet has its own separate hardware routine:

1
2

  // We have our own version of this code.
  #define MICROPY_HW_ENABLE_RNG (0)

Defined, but zero. The guard saw that it existed, stayed quiet, and the build went through. The library called for its randomness by a function name. The wallet’s own hardware routine went by a different name, and the software fallback was the only thing offering the name the library asked for, so the build linked to the fallback. Both had the same shape, so nothing complained.

The software fallback is seeded once, at the first call, from values that are not secret:

1
2
3

  pad = UID_low32 ^ SysTick->VAL;
  n   = RTC->TR;
  d   = RTC->SSR;

The UID is a fixed factory serial baked into the chip, and part of it even shows up in the wallet’s USB serial number. SysTick and the RTC registers are clock and timer values an attacker can narrow down or measure on a device of their own. After that one moment, no fresh randomness comes in. From there the output is fully determined.

The result is that the number of seeds the wallet could ever produce shrank from unimaginably large down to a range a computer can search through.

On the older Mk2 and Mk3 wallets running the affected firmware, the code added no secure randomness at all. For a known serial and timer state, the seed is fully determined. The maker estimates the effective strength at around 40 bits, against the 128 bits a seed is supposed to have.

On the newer models, a later change mixed in a little randomness from the secure element, but kept only four bytes of it and reset just one 32-bit value. That leaves at most four billion possible outcomes. Four billion is a large number to a person and a small one to a computer.

That is enough. The attacker generates candidate seeds on their own machine, derives the addresses each one would produce, and checks them against the public blockchain, which is free to download. A match means a funded wallet. The public address is what each guess gets checked against. The victim’s device is never involved and could be switched off in a drawer while it happened.

Galaxy Research mapped the full sweep and found the fingerprint of a machine, not a targeted hit. The drained wallets used three different address formats mixed together: 1,183 in the modern format, seven in an older one, six in an older one still. A thief after one victim would not touch three formats at once. This was a scanner walking each derivation path and taking whatever it finds.

The sweep ran between 01:10 and 01:51 UTC on the 30th of July. 1,082.65 bitcoin lifted from 1,196 wallets across six blocks, with three empty blocks in between where nothing moved. The coins landed in four addresses and have not moved since. The first reports put the loss near 38 million, because only one of those four addresses was visible at the time. When the rest came into view, the figure grew to about 70 million.

The weakness went into shipping firmware in March 2021 and sat there for more than four years. Some coverage says eight years. That figure is the age of the software fallback code itself, written in 2018. The wallet only started using it for seeds in 2021, which is where the exposure begins, and what the number in the opening line points to.

The part that should sit with you is how it was found. The code has always been open to read. The maker’s own words are that they assume someone pointed an AI model at old versions of the firmware and it surfaced this. A few weeks before the theft, they had run one of the best available AI models over their own code to look for this kind of problem, and it found nothing serious. Their conclusion, in plain terms: attackers and defenders hold the same AI tools, and this time the tools only helped the attacker.

It was not a one-off. The same week, Anthropic published research showing one of its models cut the strength of a candidate post-quantum signature scheme in half in sixty hours, against a design that had held up to two years of expert review, and the team behind it pulled the scheme from the running. Storing a key safely is now the easier half of the problem. Finding the flaw that opens it is getting cheaper.

The attacker did make one mistake. During the sweeps, the operator used a paid account at a well-known blockchain data provider to look up the source addresses. The provider’s own logs matched the workflow with unusual precision, down to the number, timing and order of the requests. That trail has been handed to the authorities. In security, attribution is one of the hardest problems, and a paid account with a matching log pattern is a lead, not a name.

So who is exposed, and what do you do about it.

A seed is at risk if it was generated on:

• → Mk2 or Mk3 firmware 4.0.1 through 4.1.9
• → Mk4 and Mk5 before version 5.6.0, or Edge 6.6.0X
• → Q before version 1.5.0Q, or Edge 6.6.0QX

What matters is the firmware the seed was born on, not how old the device is. If you exported that seed to another wallet, the weakness went with it. Wallets on the pre-2021 firmware used the hardware chip and are clear, and the maker’s other products on different codebases are not affected.

Two things save a seed. If you added at least 50 fair, private dice rolls when you first created it, your own randomness was mixed in independently and the seed stands. If the wallet sits behind a strong, unique passphrase, that is a separate barrier an attacker still has to break, though the advice is still to move.

If you are exposed:

• → Install the fixed firmware first
• → Generate a completely new seed on the updated device
• → Verify the backup, the fingerprint and a receive address
• → Send a small test transaction, then move the rest
• → Keep the old backup until the coins have arrived

Updating the firmware does not repair a seed that already exists. And there is no test you can run on your own wallet to find out whether yours sits in the reproducible range. If you generated on affected firmware, treat it as at risk and move. After the theft, the founder of one of the largest exchanges told people the same thing in fewer words: spread your coins across more than one wallet.

The seed is not the only thing that came out of that weak generator. The same source fed paper wallet keys, seed backup split masks, device cloning and USB keys, the seed transfer feature, the web two-factor secret, and the built-in password generator. A multisig setup built only from affected devices does not escape it either, since each key in it came from the same well.

Beneath the rest, this is a randomness failure. The math of bitcoin held. The cryptography held. What broke was the one unpredictable number the keys are built on, and once that number is guessable, the keys that grow out of it are guessable too, no matter how strong the code wrapped around it. A cipher is only as good as the way it is built.

How encryption and keys work, why a strong cipher can still fall to a weak implementation, and how researchers read source code to find flaws like this one, are exactly what I teach step by step in my ethical hacking course:

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Coinkite | Block | Anthropic