Guessed, Not Stolen: Crypto’s Weak-Key Problem in 2026

Most of what this desk has written about private-key compromise in 2026 comes down to a story about theft. Someone tricked a signer into approving the wrong transaction, poisoned a remote procedure call, slipped malicious code into a build pipeline, or walked a developer through a fake job interview. The year’s defining number backs that framing up: forensic analysts now agree that compromised keys, not broken smart contracts, are the single largest cause of crypto losses, the first time that has ever been true, with roughly $1.3 billion gone in the first eight months of the year.

Hidden inside that number is a quieter kind of loss, one that does not fit the theft story at all. Nobody phished these victims. Nobody breached a server. Nobody had to touch the owner’s laptop or hardware wallet. The key was simply guessable, made with so little real randomness that a stranger with a scanning script and a few hours of compute could rebuild it from nothing. The owner held their own keys, used a genuine wallet, and wrote the recovery words on paper, and still woke up to a drained address, because the wallet’s random number generator was not random. This is compromise at birth, and in 2026 it stopped being a footnote.

The theft you cannot phish for

Every defense the industry has built this year assumes an attacker who has to get in: steal a credential, fool a human, subvert a display. Chainalysis counted more than $3.4 billion in stolen crypto during 2025, and the 2026 tallies point the same way, with crypto.news estimating that around 70% of this year’s losses trace to compromised keys, devices, and infrastructure rather than contract bugs. Weak-randomness compromise sits at the strange edge of that category. There is no intrusion to detect, because the attacker was never inside anything. They did not break your security; they skipped it, by reconstructing the one secret that all of it protects.

The wake-up call arrived in July 2026, when thieves emptied thousands of Coldcard hardware wallets without ever touching a single device. The victims were among the most careful people in crypto, cold-storage believers who had done everything right. Their keys were guessable anyway. With Bitcoin trading near $80,800 and a single well-funded address worth more than a house, the economics of guessing have never looked more attractive, and the tooling has never been cheaper.

What a private key is really made of

A Bitcoin or Ethereum private key is, underneath the seed phrase and the QR codes, just a 256-bit number. The security promise is simple: pick that number at random and the space of possibilities is so vast, larger than the number of atoms in the observable universe, that no computer will ever stumble onto yours. Brute force is not merely slow against a real key; it is hopeless, by a margin that dwarfs the age of the cosmos.

But every word of that promise rides on three of them: pick it at random. The strength lives entirely in the randomness, never in the length. A 256-bit number drawn from only four billion possibilities is not a 256-bit key in any way that matters; it is a 32-bit key wearing a 256-bit coat. Cryptographers measure that true unpredictability in bits of entropy. Around 128 bits is the floor for permanently unbreakable, and every bit you lose halves the attacker’s work. Fall from 128 bits to 40 and you have quietly handed the problem to a single graphics card. That is the hidden second clause behind not your keys, not your coins: not your entropy, not your keys. Self-custody moves the entire burden of randomness onto whatever software or chip generated the number, and most owners never see that step happen.

It helps to make the scale concrete. A properly generated twelve-word seed encodes 128 bits of entropy, about 340 undecillion possibilities, a 39-digit number; a twenty-four-word seed doubles that to 256 bits. No amount of money, hardware, or patience touches a number that size. A 32-bit seed, by contrast, holds 4.29 billion possibilities, the kind of figure a laptop counts past over a lunch break. The gap between them is not incremental, it is the difference between a vault and a screen door, and from the outside the two look identical: the same twelve English words, the same tidy address, the same confident wallet interface.

The 32-bit mistake that will not die

There is a specific engineering sin at the root of most weak-key disasters, and it keeps coming back. Programmers reach for a general-purpose pseudo-random number generator, a PRNG, when they need a cryptographically secure one, a CSPRNG. The most infamous offender is the Mersenne Twister, or mt19937, a fast and statistically excellent generator that is beloved in simulations, games, and data science, and catastrophic for keys. It is fully deterministic, and it is very often seeded with a single 32-bit value such as the system clock. Thirty-two bits means about 4.29 billion possible outputs. Modern hardware walks that entire space in hours.

A proper CSPRNG, whether the operating system’s getrandom call or a hardware generator sampling physical noise, is built to stay unpredictable even against an attacker who knows the algorithm inside out and can see some of its output. The difference is not academic. The same 32-bit shortcut turns up in a command-line tool, a browser extension, a vanity-address generator, and a hardware wallet’s firmware fallback, all built by different teams who never spoke to each other, each convinced their randomness was fine. What follows is a tour of that recurring mistake, and of what finally gets it right.

Why does the same mistake keep happening? Because the wrong tool works. A non-crypto generator produces numbers that look flawless: they pass statistical randomness tests, they never repeat in normal use, and nothing in testing reveals that the whole output is anchored to one small seed. The failure is invisible until someone tries to reverse it, and by then the keys are already in the wild. Cryptographically secure generators exist in every modern language and operating system, one function call away, yet a developer under deadline who has always reached for the fast generator rarely stops to ask whether this particular random number is the one that must never be guessed.

Coldcard 2026: cold storage, warm keys

On 30 July 2026, attackers began sweeping Coldcard wallets, and they did it from their own desks. According to TRM Labs, they took roughly 1,816 BTC, about $116 million, from more than 5,200 addresses across four waves, the first of which drained around 594 BTC from some 500 wallets in twenty-five minutes. No phishing email went out. No malware landed. Nobody visited the victims’ homes. The theft ran entirely on math.

The cause was a build-configuration error in Coldcard firmware version 4.0.1, shipped back in March 2021. The code checked whether the hardware random generator was defined rather than whether it was actually enabled, and silently fell back to a weak software generator. Seeds created on the affected firmware carried as little as 40 bits of entropy instead of the intended 128, which put them squarely inside brute-force range with no physical access required. Anyone who generated a Coldcard seed between March 2021 and the 2026 patch has to treat that seed as compromised, permanently. This is the cruelest property of a weak key: a firmware update stops the bad seeds from being made, but it cannot reach back and make an already-created key random. The only remedy is to generate a fresh seed on fixed hardware and move the coins. Cold storage protected these owners from every online threat and left them exposed to the one that was baked in at the factory.

The response was as instructive as the bug. Coinkite shipped patched firmware within days, but a patch only protects seeds made after it, so the company had to tell a slice of its most loyal customers that their recovery phrases were now radioactive. Some analysts put the eventual haul higher than TRM’s tally, with TechCrunch reporting losses above $130 million as several groups raced one another to sweep the remaining vulnerable addresses. The most uncomfortable detail, according to reporting around the incident, was that the latent flaw had sat undisturbed for more than four years and may have been surfaced with the help of AI-assisted code review, the same class of tooling defenders were counting on to protect them.

Wintermute: the vanity address that cost $160 million

In September 2022, the market-making firm Wintermute lost about $160 million when an attacker took over a privileged admin account. The account was a vanity address, one whose leading characters had been chosen for looks and gas savings, with a long run of zeros at the front. It had been generated with a popular tool called Profanity. After the hack, the security team at the DEX aggregator 1inch published a disclosure showing that Profanity pulled only 32 bits of entropy when creating addresses, which meant the private key behind any Profanity vanity address could be recovered by brute force with a manageable amount of compute. The 1inch team warned in plain terms that funds held in Profanity-generated addresses were not safe and should be moved immediately.

The lesson is almost too neat. A vanity prefix is a cosmetic flourish, a way to make a wallet look tidy or shave a little gas. Chasing that flourish, one of the most sophisticated trading firms in the market fed its administrative key into a generator that made the key guessable, then wired hundreds of millions of dollars of authority behind it. Wintermute’s chief executive Evgeny Gaevoy publicly confirmed the loss and traced it to that vanity address, framing it as an operational mistake rather than a smart-contract failure. It was neither theft in the ordinary sense nor a bug in the protocol; it was a key that had never been properly secret.

Milk Sad and Trust Wallet: the same bug, twice

If Profanity looked like a one-off, the next two cases show how stubborn the pattern is. In 2023, researchers disclosed a flaw in Libbitcoin Explorer, a command-line Bitcoin toolkit favored by developers and power users. Its bx seed command used the Mersenne Twister seeded with 32 bits of system time, so every supposedly random seed came from the same four-billion-value pool. The vulnerability, catalogued as CVE-2023-39910 and nicknamed Milk Sad after the first two words of the mnemonic a default all-zero seed produces, was exploited in the wild through the summer of 2023, with wallets drained as researchers watched. The people most exposed were exactly those who thought a hardcore command-line tool was the safe, expert choice.

A year earlier, in November 2022, Trust Wallet’s newly launched browser extension made the identical error. Its early versions, 0.0.172 through 0.0.182, generated seed phrases with a Mersenne Twister seeded by a single 32-bit value, collapsing the universe of possible phrases to roughly four billion, a number a consumer graphics card can grind through in hours, with no interaction from the user at all. The flaw was reported to Binance on 17 November 2022 and fixed within days. As Ledger’s Donjon security team documented, roughly $170,000 was actually stolen in the wild, but something like $30 million sat exposed; Trust Wallet later published a post-mortem and reimbursed affected users. Two independent teams, one building for terminal-loving Bitcoiners and one building for mainstream mobile users, shipped the same 32-bit bug within a year of each other.

Randstorm: a decade you cannot patch

The most sprawling case is also the oldest. In November 2023, the recovery firm Unciphered disclosed Randstorm, a weakness in the widely used BitcoinJS library that underpinned a generation of web wallets, including much of early Blockchain.info, from 2011 to 2015. The library’s SecureRandom function leaned on the weak Math.random implementations in period browsers, yielding as little as around 48 bits of entropy, and worse for wallets made before March 2012. Unciphered stumbled on the flaw in January 2022 while trying to recover a customer’s wallet from 2014, and estimated that as many as 1.4 million BTC may sit in wallets built on the vulnerable code.

Randstorm is the clearest illustration of why weak keys are so much worse than ordinary bugs: you cannot patch a key. A vulnerable wallet minted in 2013 carries its flaw forever, and the only fix is to move the coins to a fresh address. But many of those owners are unreachable, have lost their credentials, have died, or have no idea they are exposed. The vulnerability just sits on the chain, a slow-motion liability that any sufficiently patient attacker can keep mining. Unciphered built its write-up around the idea that you cannot patch a house of cards, and the phrase fits the entire category.

Before wallets: Android and the brainwallet graveyard

Two older episodes teach the rest of the lesson, because entropy can fail at two different moments: when a key is born, and every time it signs. In August 2013, a broken implementation of Java’s SecureRandom on Android left every Bitcoin wallet generated on the platform at risk, across the popular apps of the day. It failed twice over. The generator produced weak keys, and it also produced repeated signing values. Every ECDSA signature needs a fresh random number, and if the same one is ever reused for two signatures under the same key, the private key can be recovered with schoolbook algebra, the same class of mistake that once cracked a games console’s master key. Attackers scanned the chain for those repeats and drained around 55.8 BTC, prompting a formal Bitcoin.org security advisory.

The purest case of all is the brainwallet, where the user supplies the randomness by choosing a passphrase that is hashed straight into a key. Humans are dreadful sources of entropy. At DEF CON in 2015, the researcher Ryan Castellucci released a cracking tool and showed that one dollar of compute could test hundreds of millions of passphrases, and that the overwhelming majority of brainwallets ever funded had already been swept, often within seconds of receiving coins. He once cracked a brainwallet holding 250 BTC and tracked down the owner to return it. Predictable input, predictable key: the machine does not care whether the shortcut came from a lazy generator or a memorable phrase.

Seven heists, one root cause

Different tools, different decades, different victims, one failure. The table below lines them up by the only thing that matters, how much genuine randomness stood behind the key.

What ties these together is not just the flaw but the way the money leaves. Weak keys create a scanning game, not a targeting game. The attacker does not need to know who you are or send you anything. They generate candidate keys across the small keyspace, derive the corresponding addresses, and check them against a downloaded list of funded addresses from the public chain. Every hit with a balance is swept in a single transaction. For a 32-bit space that is a few hours on commodity graphics cards; for a brainwallet it is a dictionary run; for the Coldcard seeds, the space had shrunk to roughly 40 bits, narrow enough to be worth the electricity. Automated bots watch fresh deposits and can empty a newly funded weak address within seconds, the same reflex that powers the repeat-offender playbook behind so many bridge failures.

Set against that, the honest keyspace is safe for exactly one reason: brute force must cost more than it can ever win. It is the same economic wall that protects Bitcoin’s ledger from a 51% takeover, where an attack only makes sense if it is cheaper than playing by the rules. Good entropy keeps the search astronomically more expensive than any prize; weak entropy knocks the wall flat.

The numbers explain why some spaces fall and others never will. A single modern graphics card can test hundreds of millions to billions of candidate keys per second, so a 32-bit space of 4.29 billion is exhausted in seconds to minutes, and a 40-bit space of about 1.1 trillion, the Coldcard range, in hours to days on a small rig. Push to the roughly 48 bits of the Randstorm wallets, about 281 trillion, and you need a serious cluster and real motivation, which is exactly why those coins have been drained selectively rather than all at once. Every additional bit doubles the work, so the jump from 40 to 128 bits is not eighty-eight steps harder, it is two to the eighty-eighth power harder, which is the whole ballgame.

Why born-broken keys are back in 2026

The category never disappeared, but three forces revived it this year. Compute got cheaper and more parallel, so searching a 40-bit space is now trivially affordable. AI-assisted tooling helps attackers recognize weak-key fingerprints and automate the derive-and-check pipeline at scale, part of the broader 2026 shift in which stolen and guessed keys eclipsed code bugs. And years of cold-storage evangelism parked an enormous amount of value in self-custody, so a single batch of weak firmware can expose nine figures at once. The Coldcard sweep was not a new kind of attack; it was an old attack meeting a target-rich environment. Forbes counted first-half 2026 losses at about $1.32 billion, with wallet breaches the biggest single category, and the weak-key subclass is the part of that story with no human to blame and no server to patch.

Where good randomness comes from

The fix is unglamorous and completely understood. Use a cryptographically secure generator seeded by real physical entropy. A good hardware signer contains a secure element with a hardware true-random generator that samples electrical noise; the operating system’s own generator is the software baseline; both are designed to stay unpredictable even against an attacker who knows everything about how they work. The standard behind seed phrases, BIP-39, specifies 128 to 256 bits of entropy, and the twelve or twenty-four words are simply a checksummed encoding of that entropy, not the entropy itself. Twelve words generated correctly are unbreakable. Twelve words from a 32-bit seed are theater.

The part the industry is still building is proof. Today most owners simply trust that the randomness was good, which is precisely the assumption Coldcard quietly violated. The frontier is making entropy attestable: open, reproducible firmware whose behavior anyone can verify; secure elements that can prove which generator produced a key; and remote attestation so a custodian can demonstrate, rather than assert, that a key was born inside a sound process. Until that is standard, the single most useful question a buyer can ask a wallet or custodian is embarrassingly basic, and almost never answered on a spec sheet: where, exactly, did my randomness come from, and can you show me?

For the genuinely cautious, the strongest move is to stop trusting a black box you cannot inspect: generate entropy yourself with dice or coin flips and feed it into an audited, offline tool, the same discipline careful validators use when generating keys for solo staking. A few dozen dice rolls give you more honest, countable randomness than any generator whose innards you have to take on faith. The frontier now is verifiability: proving the randomness was good rather than assuming it. The table below compares the common sources.

Killing the single point of randomness

Every incident in this piece shares a structural weakness beneath the specific bug: one machine, one library, one moment produced the whole key, so one flaw doomed it. The most durable defense is to remove that single point of failure entirely. Distributed key generation, the backbone of modern multi-party computation custody, has several parties each contribute their own randomness and jointly compute a key that no single party ever holds in full. The private key is never assembled in one place, not at creation, not at rotation, not at signing. To reproduce it, an attacker would have to poison everyone’s randomness at once, not just find the one weak generator.

This is a large part of why institutional custody moved toward MPC and threshold signatures, and why smart-account and social-recovery designs matter beyond convenience: they let a key be rotated or recovered when its provenance is in doubt, instead of remaining a single permanent secret you can never take back. The trade-off is real and worth stating plainly. MPC internalizes trust into infrastructure you cannot fully audit on-chain, and the key-generation ceremony still has to use sound randomness of its own; it is not magic. But it structurally removes the single-source-of-entropy failure that every case in the table above has in common, which is more than any amount of careful single-device key generation can promise.

What to do if your key might be weak

If any wallet you control was created by software or hardware on the following list, treat the seed as compromised and move the funds now, before someone else does. A patch does not help; only a brand-new key does.

• Any Coldcard seed created between March 2021 and the 2026 firmware patch
• Any address generated with the Profanity vanity tool
• Any wallet made in the affected 2022 Trust Wallet browser extension, versions 0.0.172 through 0.0.182
• Any seed from the Libbitcoin bx seed command, the Milk Sad flaw
• Any web wallet built on pre-2016 BitcoinJS, including much of early Blockchain.info
• Any brainwallet, without exception

When you rebuild, do it deliberately.

• Generate new keys only on audited, up-to-date hardware or software with a genuine cryptographic generator, and verify firmware versions and signatures
• Add a BIP-39 passphrase, the 25th word, so that even a leaked or weak seed is not enough on its own
• Where you can, contribute your own dice entropy, or split the key across a multisig or MPC setup that mixes independent sources of randomness
• Move the coins to the new address; never assume a patch has repaired an old key

None of this requires trusting a headline or a brand. It requires knowing where your randomness came from, which is the single question almost no wallet asks you to answer, and the one every victim in this story wishes they had.

Who answers when a key is born broken

Almost none of these losses happened at a regulated custodian, which is the uncomfortable core of the accountability problem. Self-custody puts the burden of randomness, and therefore the loss, entirely on the user. In the United States, the SEC rescinded its restrictive custody accounting guidance in January 2025, replacing Staff Accounting Bulletin 121 with SAB 122 and clearing the way for banks to custody crypto again. Yet neither that guidance nor the Advisers Act custody rule sets any standard for how a qualified custodian must generate the randomness behind its keys or prove it was sound. Key provenance is an unexamined assumption. The same gap runs through the EU’s MiCA regime, which defines custody as safekeeping and controlling the means of access, meaning the private keys themselves, and places the burden of proof on the provider, yet says nothing about the quality of the entropy that made those keys.

For a self-custody victim, the practical recourse is close to nil. There is no chargeback, no deposit insurance, and usually no defendant, because the attacker only ran math against a public chain. A handful of custodians and exchanges carry crime insurance, but those policies are written around theft and infrastructure failure, not around the possibility that a key was guessable from the day it was made, and an insurer could reasonably argue that a weak-entropy key was never truly secret to begin with. That leaves provenance as the missing control: a documented, auditable answer to how each key was generated, retained the way a custodian retains a transaction log.

The deeper issue is that audits certify code, not coin-flips. As CertiK co-founder Ronghui Gu told Forbes, “A protocol can pass a flawless code audit and still lose millions because of a compromised admin key.” A wallet can be open-source, reproducible, and formally audited, and still ship a build-configuration bug that quietly swaps the good generator for a bad one, which is precisely what happened to Coldcard. The financial plumbing built on top of these keys, from exchange deposit addresses that now run code to institutional custody stacks, inherits whatever randomness sat at the bottom. Until provenance of key generation becomes something a custodian must attest and a regulator can check, born-broken keys will stay the compromise nobody is watching for.

Frequently Asked Questions

Can someone guess my Bitcoin or Ethereum private key?

If it was generated with proper randomness, no. A 256-bit key drawn from a secure generator lives in a space so vast that brute force is hopeless, even for every computer on Earth running until the sun dies. The danger appears only when the wallet used a weak or predictable random number generator, which quietly shrinks the real keyspace to something a single laptop can search.

How do I know if my wallet was hit by a weak-randomness bug?

Check whether your wallet, firmware, or tool appears in a published disclosure: Coldcard firmware from March 2021 to the 2026 patch, the 2022 Trust Wallet browser extension, Profanity vanity addresses, the Libbitcoin bx seed command, or pre-2016 web wallets built on BitcoinJS. If it does, treat the seed as compromised and move your funds to a freshly generated wallet.

Does updating my firmware fix a weak key?

No. A patch stops new bad keys from being created, but it cannot make an already-generated key random after the fact. You have to create a brand-new seed on patched hardware and migrate your funds to it; the old key stays guessable forever.

What does entropy mean in a crypto wallet?

Entropy is the amount of true unpredictability behind your key, measured in bits. Standards call for 128 to 256 bits, and a seed phrase is just a human-readable encoding of that entropy. If the underlying randomness is weak, the words look perfectly normal but the key behind them is guessable.

Are hardware wallets immune to this?

Usually, because they generate keys from a hardware true-random generator, but not automatically. The 2026 Coldcard incident showed that a firmware bug can silently disable the good generator. Use audited, current firmware, verify the device signatures, and where possible add your own dice entropy or use a multi-party setup.

Anneke de Vries is HOGE Wire’s security desk editor, covering exploits, custody, and on-chain forensics.