The Seed Flaw That Broke Air-Gapped Wallets

The first wave took 594 BTC - about $38 million - out of roughly 500 wallets in twenty-five minutes. None of those wallets were hot. None had been connected to a computer. They were air-gapped devices whose owners had done everything the manuals recommend.

By mid-August, the total had passed 1,778 BTC, around $112 million at the time, and the running figure now sits near $130 million. This significant breach was caused not by a phishing site or a malicious signature, but by a firmware bug from 2021 that made some wallet seeds guessable, fundamentally altering the guarantees of hardware wallet security.

What actually broke

A wallet seed refers to the initial random data used to generate private keys, and it is pivotal to cryptocurrency security. A wallet seed is generated from randomness. That randomness is measured in bits of entropy, and the industry standard is 128 bits - a number large enough that brute-forcing it is not a computing problem but a physics problem.

On affected devices, the flaw reduced that figure to roughly 40 bits. Forty bits is not a physics problem. It is an afternoon with rented hardware.

This is the part that makes the incident structurally different from every other wallet story. Nothing was stolen from the device. The attacker never touched it, never needed the PIN, never saw the screen. Given a seed generated in a predictable range, the private keys can be reconstructed from anywhere in the world, and the owner has no way to notice until the balance moves.

Hardware wallet security rests on one assumption: that the number generated inside the device is unknowable outside it. When entropy collapses, every other protection in the stack - secure element, passphrase, PIN, tamper mesh - becomes decoration.

Why air-gapping did not help

Air-gapping is a security measure that involves isolating a device from any network connection to prevent unauthorized access. Air-gapping defends against a specific threat: a compromised computer reaching the keys. It works well for that.

It does nothing at all against a key that was weak at birth. The signing device can be sealed in a vault, wrapped in foil, never powered near a network, and the funds still leave because the attacker is not attacking the device. They are attacking the mathematics that produced the seed.

That distinction is worth internalizing, because most guidance about hardware wallet security implicitly assumes the attacker must reach your hardware. Seed generation is the one failure mode where they do not.

The uncomfortable part: how the flaw was found

Coinkite has suggested the attackers may have used AI to comb through older versions of its open-source firmware and surface the weakness.

Galaxy Research, tracking the drains, described the campaign as deliberate, programmatic, and potentially orchestrated with a large language model. By early August, they had mapped roughly $88.6 million across 4,585 addresses; the attacks arrived in three major waves plus dozens of smaller incidents.

Read that carefully. The code had been public since 2021. Human reviewers had looked at it for years. What changed was not the code but the cost of reviewing it: an attacker with a model can now read every historical version of every open-source firmware in a way that was previously uneconomic.

The defensive irony is that Coinkite's own three-week remediation review also used outside researchers alongside AI models. The same capability now works both sides of the line, and the side with more patience wins.

What was fixed

The company urged owners of Mk4, Mk5, and Q devices to move to firmware 5.6.1 or 1.5.1Q. The release addressed transaction signing, USB data handling, firmware validation, Delta Mode, and wallet backups.

The most telling change is procedural rather than technical: seed generation now requires the user to contribute randomness manually, with a minimum number of key presses before a wallet can be created. The device no longer trusts itself alone to be random.

That is a sensible correction, and it also quietly concedes the deeper point. Randomness is the single hardest thing to verify in a security product because a weak random number looks exactly like a strong one.

What this means if you own any hardware wallet

Not a Coldcard user? The lesson still applies because this class of hardware wallet security failure is not brand-specific. Any device that generates seeds can generate them badly, and the owner cannot tell by looking.

Update firmware, but understand what an update does and does not do. New firmware fixes future seed generation. It does not repair a seed that was already created weakly - those keys stay guessable forever, which is why the affected users had to move funds rather than patch and relax.

Treat seed generation as the highest-risk moment in the life of a wallet. It happens once, takes thirty seconds, and determines everything afterward. If your device offers a way to add your own entropy - dice rolls, key presses, coin flips - use it, even though it feels like theatre.

Do not reuse a seed across devices or restore an old seed onto new hardware without knowing which firmware version created it. In this incident, the vulnerable window stretched back years, and plenty of owners had long forgotten which build they were running when they first set up.

Split holdings across wallets generated at different times, ideally on different devices from different vendors. That sounds paranoid until a single vendor-wide entropy bug takes 4,585 addresses at once.

How to check exposure

Auditing your own hardware wallet security starts with the firmware history of the specific device, not the model line. Vendors publish which builds were affected; matching your creation date against that list is the only reliable check.

If the wallet was created inside an affected window, treat the seed as compromised regardless of whether funds have moved. Attackers work through lists, and a quiet address only means your turn has not arrived.

Migration, not patching, is the fix. Generate a new seed on updated firmware, verify the receive address on the device screen, move funds, and retire the old seed permanently - never as a backup, never as a spare.

And watch for the follow-up scam. Every incident of this size is followed within days by "recovery services" and fake vendor support asking for the seed phrase they claim to be rescuing.

The broader lesson

Open source is often treated as a security guarantee. It is not one. It is a precondition for review, and review is a separate activity that somebody has to actually perform, fund, and repeat.

For seven years this firmware was public and popular. The bug survived anyway because nobody had a reason to re-read old commits until the economics changed.

Hardware wallet security is still the right default for meaningful balances - self-custody with a dedicated signing device remains far safer than leaving keys on a laptop. What this incident revises is the assumption of permanence. A device that was secure in 2021 is not automatically secure now, and the audit that mattered was the one nobody ran.