The COLDCARD RNG Vulnerability: How a “Random” Bitcoin Seed Became Guessable

A hardware wallet can be completely offline, your seed phrase can never leave the device, and an attacker can still steal your Bitcoin — if the seed was never truly random to begin with.

That is essentially what happened with the 2026 COLDCARD RNG vulnerability.

This one is confusing because phrases like RNG, entropy, PRNG, seed phrase, private key, and deterministic output get thrown around together. Then someone says:

“Attackers brute-forced the seed.”

And the natural reaction is:

Wait. They guessed 24 random words?

Not exactly.

That distinction is the entire vulnerability.

Reading Promise

By the end of this, you should understand:

• What an RNG actually does.
• What "entropy" means.
• Why Bitcoin wallets need randomness.
• How a perfectly normal-looking 24-word seed phrase can still be weak.
• What went wrong inside COLDCARD.
• What "deterministic" means here.
• Whether attackers were literally guessing seed phrases.
• How attackers could know when they had found a real wallet.
• Why Bitcoin's public blockchain actually helps the attacker verify guesses.
• Why an offline hardware wallet didn't prevent this.
• Why updating the firmware does not fix an already-created wallet.
• Why dice rolls and BIP-39 passphrases change the equation.
• Which COLDCARD models and firmware are affected.

No assumed Bitcoin cryptography knowledge.

The 30-Second Version

A Bitcoin wallet starts with a secret random number.

That random number ultimately produces your:

The security assumption is simple:

The original random number is so unpredictable that nobody else could possibly generate it.

COLDCARD intended to generate that randomness using a hardware True Random Number Generator, or TRNG.

But because of a firmware integration mistake introduced around the 2021 code migration, wallet generation on affected firmware ended up using a deterministic software pseudorandom number generator in a way COLDCARD did not intend. On Mk2/Mk3 devices, important inputs to that generator came from things such as device and timing state rather than strong cryptographic randomness. Later devices added secure-element randomness, but not enough of it reached the relevant generator state to restore the intended security margin.

So instead of:

An astronomically huge universe
of possible wallets

attackers could potentially work with:

A much smaller family
of wallets the buggy software
was capable of producing

Then they could do something extremely important:

Candidate seed
     ↓
derive Bitcoin address
     ↓
look at public blockchain
     ↓
Does this address contain Bitcoin?
     ↓
YES → candidate is correct
NO  → try another

They did not have to ask the COLDCARD whether their guess was correct.

Bitcoin itself gave them the answer.

Block's researchers describe a wallet xpub, address, or public key as a candidate-validation oracle: something that lets an attacker determine whether a candidate seed is correct.

That is the vulnerability in one picture.

Part 1: Forget Bitcoin for a Second

Imagine I tell you:

I'm thinking of a number.

You ask:

Between what and what?

I answer:

Between 1 and 340,282,366,920,938,463,463,374,607,431,768,211,456.

Good luck.

That number is approximately:

2^128

There are about:

340 undecillion possibilities.

Brute forcing that is effectively impossible.

Now imagine that I claim to choose from that enormous range, but because of a software bug my number generator really behaves more like:

pick one of a much smaller,
predictable family of numbers
based partly on:

- the device
- the clock
- timing information
- known internal state

My output might still look like:

183749108374910283749...

It looks random.

But looking random and being unpredictable are two very different things.

That distinction is fundamental to cryptography.

Part 2: WTF Is an RNG?

RNG simply means:

Random Number Generator.

Cryptography constantly needs unpredictable numbers.

Passwords.

Encryption keys.

TLS session keys.

Authentication tokens.

Private keys.

Bitcoin wallets.

The important property isn't really:

"Does this number look messy?"

It is:

Could somebody else predict or reproduce it?

TRNG vs PRNG

There are two terms worth knowing.

TRNG

True Random Number Generator

A hardware TRNG gets randomness from some physical phenomenon inside the hardware.

Very simplified:

COLDCARD devices contain hardware intended to provide this kind of entropy.

PRNG

Pseudorandom Number Generator

A PRNG is an algorithm.

Give it some starting state:

State = 12345

and it produces something that looks random:

48172918
98217341
01749102
...

But run the same algorithm with the same starting state again:

State = 12345

and you get:

48172918
98217341
01749102
...

Again.

That is what deterministic means.

Same starting conditions:

will give you:

every time.

Important: PRNG Does NOT Automatically Mean Insecure

This matters.

Modern cryptography routinely uses cryptographically secure pseudorandom number generators, or CSPRNGs.

Those are designed specifically so that knowing previous outputs doesn't make future outputs practically predictable.

So the COLDCARD problem was not simply:

"They used software randomness. Software randomness bad."

That would be wrong.

The problem was the particular generator path, how it was initialized, and how secure entropy was — or was not — incorporated.

COLDCARD's affected firmware unexpectedly reached MicroPython's Yasmarang software generator instead of the intended hardware RNG path.

That brings us to the bug.

Part 3: What Is "Entropy"?

Entropy is one of those words security people make sound more complicated than it needs to be.

For our purposes:

Entropy is unpredictability.

More entropy:

Less entropy:

Think of passwords.

This password:

password1

contains very little useful unpredictability.

This:

jN8#vQ2!fzP6$LmX

contains considerably more.

Both are strings.

Both could be stored in the same password field.

Their appearance as a string doesn't tell you the size of the attacker's search space.

Seed phrases work similarly.

Part 4: Your 24 Words Aren't the Magic Part

People naturally think the 24 words themselves provide the security.

They don't.

The randomness behind the words provides the security.

BIP-39 essentially takes binary entropy and turns it into human-manageable words. Under BIP-39, a 24-word mnemonic encodes 256 bits of initial entropy plus checksum information.

Conceptually:

The words are an encoding.

Imagine This

Suppose I wrote software that does this:

Choose one random number between 1 and 100.

Then I take the number and run it through an algorithm that turns it into a beautiful 24-word Bitcoin seed phrase.

I might get:

word word word word word word
word word word word word word
word word word word word word
word word word word word word

It looks exactly like a real wallet seed.

But there were only:

100

possible seeds my program could ever generate.

An attacker wouldn't need to test the astronomical universe of all 24-word phrases.

They would need to test:

Seed candidate #1
Seed candidate #2
Seed candidate #3
...
Seed candidate #100

The formatting doesn't restore the lost randomness.

Neither does hashing it afterward.

Block specifically noted this problem with the affected COLDCARD design: hashing the RNG output can make the resulting bytes look uniformly distributed, but hashing cannot magically increase the number of possible starting states.

In other words:

Not:

Cryptography doesn't work like that.

Part 5: So What Actually Went Wrong With COLDCARD?

This is where the story gets interesting.

COLDCARD already had code capable of accessing its hardware random-number generator.

The hardware RNG itself wasn't simply sitting there producing bad numbers.

Instead, this was essentially a software integration / build problem.

COLDCARD describes it as a link-time integration error rather than a hardware TRNG failure.

Before the Regression

Earlier wallet generation used a path conceptually like:

Block traced the earlier code to a function using the board's hardware RNG directly.

Then Things Changed

Around the March 2021 migration to libNgU, wallet generation changed from the previous hardware-RNG call to something effectively resembling:

ngu.random.bytes(32)

The expectation was that the underlying RNG path would ultimately reach the appropriate hardware random-number implementation.

But it didn't.

A configuration value existed:

MICROPY_HW_ENABLE_RNG = 0

The intent was essentially:

We aren't using MicroPython's RNG implementation because COLDCARD provides its own.

But another component checked whether that setting was defined, rather than checking whether it was enabled.

Conceptually, think:

Is MICROPY_HW_ENABLE_RNG defined?

instead of:

Is MICROPY_HW_ENABLE_RNG actually enabled?

Since:

MICROPY_HW_ENABLE_RNG = 0

is still technically defined, the check passed.

The build succeeded.

And the wrong RNG implementation was linked into the path used by wallet generation.

This is a wonderfully awful example of why security failures can happen several layers away from the actual cryptography.

The cryptographic algorithm wasn't necessarily broken.

The hardware wasn't necessarily broken.

The compiler wasn't necessarily broken.

The individual pieces largely did what they were programmed to do.

They were just connected incorrectly.

Part 6: What Did It Use Instead?

MicroPython's fallback implementation used a software generator called Yasmarang.

Its initialization incorporated values including things such as:

device UID
     +
system tick/timer state
     +
real-time-clock state

Block's analysis shows the fallback being initialized from the MCU UID and timer-related registers.

Those values can certainly change.

But:

Changing does not mean cryptographically random.

Consider:

Current time:
3:14:27 PM

That changes every second.

It isn't random.

Likewise:

Device serial number:
1234567

might be unique.

But unique isn't random either.

Unique ≠ Secret ≠ Random

These are different concepts.

DEVICE SERIAL NUMBER

Unique?        Maybe yes.
Secret?        Not necessarily.
Unpredictable? Not necessarily.
Random?        Not necessarily.

That's hugely important.

A cryptographic secret needs unpredictability.

Part 7: What Does "Deterministic Output" Actually Mean?

This is where the earlier confusion usually happens.

It does not mean:

Every COLDCARD generated the same seed.

And it does not mean:

There were only 10 possible COLDCARD seeds.

It means that if an attacker can reproduce or sufficiently constrain the relevant starting conditions, the resulting software RNG stream can also be reproduced.

Very simplified:

Device state
UID
Timer
RTC
Previous RNG activity
      │
      ▼
  Yasmarang
      │
      ▼
random-looking bytes
      │
      ▼
Bitcoin seed

If the attacker can determine enough of:

Device state
UID
Timer
RTC
RNG-call history

then instead of asking:

"Which seed out of essentially the entire universe did Dan get?"

the question becomes more like:

"Which output could this known algorithm have produced under the plausible starting conditions?"

That is an enormously different problem.

Block explicitly cautions that this doesn't mean every attacker can instantly recover every seed. Practical attack cost depends on how well things such as UID information, timer state, prior RNG calls, and other conditions can be constrained.

But the security model has already changed dramatically.

Part 8: Are Attackers Guessing Seed Phrases?

Sort of.

But saying:

"They guessed the seed phrase."

gives the wrong mental model.

The attacker doesn't necessarily sit there doing:

abandon apple zebra horse...
NO

window table dog pizza...
NO

correct battery bitcoin...
NO

trying random words.

Instead, the attack is conceptually:

Reproduce buggy RNG behavior

          ↓

Generate candidate entropy

          ↓

Convert candidate into the same
wallet structure COLDCARD would

          ↓

Derive Bitcoin keys

          ↓

Derive Bitcoin addresses

          ↓

Compare those addresses
with known blockchain activity

The "guessing" happens much earlier.

They're guessing or enumerating possible RNG states/outputs.

The seed phrase simply falls out of the process.

Part 9: But How Does the Attacker Know Which Guess Is Correct?

This is the clever part.

Bitcoin addresses are public.

Bitcoin transactions are public.

The blockchain is public.

Suppose the attacker generates:

Candidate seed #938174

That candidate deterministically produces:

Maybe the result is:

bc1qABC...

The attacker asks:

Has bc1qABC... ever appeared on the blockchain?

If no:

Candidate rejected.

Try the next one.

Then eventually:

Now things get extremely interesting.

Because if that candidate seed generates an address known to belong to a funded wallet, the attacker has effectively found the secret necessary to control it.

Block calls public wallet information a candidate-validation oracle for exactly this reason.

Attack Flow

The whole attack now looks like this:

             BUGGY COLDCARD RNG
                     │
                     ▼
       smaller candidate universe
                     │
                     ▼
            Candidate RNG state
                     │
                     ▼
               Candidate seed
                     │
                     ▼
             Candidate private key
                     │
                     ▼
              Candidate address
                     │
                     ▼
           ┌───────────────────┐
           │ Public blockchain │
           └─────────┬─────────┘
                     │
              Does it match?
                  /      \
                NO        YES
                │          │
             continue      ▼
                        seed found
                            │
                            ▼
                      control funds

Notice what is not in that diagram:

Hack user's laptop

Steal seed backup

Plug into COLDCARD

Guess COLDCARD PIN

Break Bitcoin encryption

Intercept USB

Access hardware wallet remotely

None of those is fundamentally required if the secret was predictable when it was originally created.

Part 10: So How Do Attackers Know Which Bitcoin Wallets Are COLDCARD Wallets?

This requires another subtle distinction.

Bitcoin does not normally publish:

THIS ADDRESS WAS CREATED BY A COLDCARD MK3
SERIAL NUMBER 123456
FIRMWARE 4.1.2

An ordinary Bitcoin address does not inherently announce:

"Hi, I'm vulnerable."

So an attacker isn't necessarily starting with a perfect list of:

All vulnerable COLDCARD owners

Instead, the more powerful approach is essentially the reverse:

Think about that difference.

You don't necessarily start with:

"Find Dan's wallet and crack it."

You can start with:

"Generate candidate wallets produced by the vulnerable process and see whether any of them correspond to real Bitcoin."

That is much closer to a giant cryptographic scavenger hunt.

And because Bitcoin's ledger is public, the attacker can perform much of the candidate checking without interacting with victims at all.

Part 11: They're Generating Wallet Addresses?

Yes.

But they're not creating new wallets on the Bitcoin network in the way you might initially imagine.

Remember:

Those calculations can all happen offline.

You don't "register" a Bitcoin address with Bitcoin.

So an attacker can take:

Candidate Seed A

and calculate:

Address A

Then:

Candidate Seed B

produces:

Address B

Then:

Candidate Seed C

produces:

Address C

And so on.

They can generate enormous numbers of candidate addresses locally.

They're effectively asking:

If COLDCARD produced this particular weak RNG output, which Bitcoin addresses would the resulting wallet own?

Then they compare those addresses to blockchain history.

That's the missing mental model.

Part 12: Why Can't Bitcoin Tell the Difference?

Because from Bitcoin's perspective, the resulting key is still mathematically valid.

Bitcoin sees:

Bitcoin has no way to ask:

"Was this private key generated using excellent randomness?"

A valid private key generated with terrible randomness is still a valid private key.

It's like a password system.

Suppose my password is:

123456

The server doesn't say:

"You chose that predictably, therefore it is not a password."

It works perfectly.

It's just easy for someone else to discover.

The same principle applies here.

Part 13: This Wasn't Bitcoin Being Cracked

This distinction matters.

Attackers did not break:

SHA-256

They did not break:

secp256k1

They did not discover some magical shortcut for reversing Bitcoin addresses into private keys.

Instead, they attacked something far more mundane:

How was the secret originally chosen?

The mathematics protecting Bitcoin can be extraordinarily strong while the system still fails if the private key originates from insufficient randomness.

Think of a bank vault with an incredibly strong lock.

The lock isn't particularly useful if somebody chooses:

Combination: 1-2-3-4

Part 14: Why an Air-Gapped Hardware Wallet Didn't Save You

This is probably the most uncomfortable lesson from the vulnerability.

Hardware wallets are designed primarily around protecting secrets after they exist.

Conceptually:

PRIVATE KEY

             Internet
                X
                │
        ┌───────┴────────┐
        │ Hardware Wallet │
        │                 │
        │   PRIVATE KEY   │
        │      stays      │
        │     inside      │
        └─────────────────┘

Great.

But suppose the private key was predictable from the beginning.

Then you get:

Attacker
   │
   │ does not steal secret
   │
   ▼
reconstructs same secret independently

The private key never has to leave the COLDCARD.

The attacker creates their own copy.

That bypasses the entire point of keeping the original key offline.

An Analogy

Imagine you own a safe.

Your combination never leaves the safe company.

Nobody photographs it.

Nobody intercepts it.

Nobody breaks into your house.

Excellent.

Except the safe company has a bug in its combination generator:

Combination =
house construction year
+
street number
+
minute safe was installed

The combination remains secret inside the safe.

But secrecy is irrelevant if somebody can independently reconstruct it.

That's essentially the category of failure we're discussing.

Part 15: The Mk2/Mk3 Case vs. Newer COLDCARDs

This is another area where articles can become misleading.

The impact was not identical across all COLDCARD generations.

Mk2 / Mk3

For affected Mk2/Mk3 firmware, the problematic software RNG path did not receive the cryptographically secure reseeding that later models added.

COLDCARD's current technical assessment estimates an effective search space around 40 bits under its stated attack assumptions.

For perspective:

2^40 ≈ 1.1 trillion

That sounds enormous.

But cryptographic security normally deals with numbers vastly beyond human intuition.

Compare:

2^40
≈ 1,099,511,627,776

with:

2^128
≈ 340,282,366,920,938,463,463,374,607,431,768,211,456

Those are not remotely comparable security levels.

Part 16: Mk4, Q and Mk5 Were Better — But Still Affected

Later devices added randomness from secure elements.

So this wasn't simply:

same exact Mk3 bug

with a new case.

There was additional protection.

However, Block found that the secure-element data was hashed and only four bytes — 32 bits — were passed into the relevant reseed() operation, replacing one state word in Yasmarang.

COLDCARD's broader attack model currently estimates approximately 72 bits of effective entropy for affected Mk4, Q, and Mk5 seeds rather than the intended security target.

Wait — 32 Bits or 72 Bits?

Both figures appear in reporting.

This is where precision matters.

Block's analysis says that once the fallback RNG state and call history are fixed, the secure-element reseed creates at most:

2^32

securely distinguished output streams.

That is describing the cryptographically secure unknown introduced by that particular reseed operation.

COLDCARD's approximately:

72 bits

figure is a broader estimate of effective attack complexity under its assumptions, including other state an attacker may need to search or constrain.

So don't read:

32 vs 72

as:

"One of them can't do math."

They're modeling somewhat different pieces of the attack.

And both organizations caution that real-world recovery cost depends on exactly what the attacker knows about a particular device's state and history.

Part 17: How Serious Is 72 Bits?

Much stronger than 40 bits.

But substantially weaker than the expected security margin.

And this is another reason not to casually say:

"Oh, attackers just brute-forced 2^72 seeds."

That oversimplifies the actual attack.

The goal is to constrain several variables and exploit structure in the vulnerable generation process.

Think:

all possible Bitcoin seeds

versus:

seeds this specific buggy
algorithm could plausibly have
generated under plausible states

That's the key distinction.

Part 18: Why Was This So Difficult to Notice?

Because the output looked fine.

Imagine running the device ten times and getting:

7f29ac31...
b19d06ef...
58ad9032...
93c01fe8...

Nothing immediately screams:

BROKEN RANDOMNESS

A deterministic PRNG can produce numbers that look extremely random statistically.

Block also notes that COLDCARD had a basic health check designed to catch obvious repeated RNG values.

But a deterministic PRNG normally produces different consecutive outputs.

So it can easily pass a test like:

output1 != output2

while still being predictable to someone who knows the state.

This is the difference between:

"Does this output look random?"

and:

"Can an adversary predict this output?"

The second question is what cryptography actually cares about.

Part 19: Why Open Source Didn't Automatically Save Anyone

COLDCARD's firmware source was publicly available.

Yet the issue survived for years.

That isn't necessarily surprising.

The vulnerable behavior crossed several pieces of software:

A reviewer could inspect:

the hardware RNG implementation

and confirm:

"Yep. Looks good."

That still doesn't prove that:

New Wallet

actually reaches that implementation at runtime.

COLDCARD says prior review verified that the intended hardware RNG code was present, but did not verify the complete end-to-end symbol resolution from wallet generation through the relevant submodules.

That's an incredibly valuable software-security lesson:

Having secure code somewhere in the binary is not the same thing as proving the security-critical operation actually uses it.

Part 20: The Failure Chain

The vulnerability is easier to understand when we stop treating it as one giant mysterious "RNG bug."

It was a chain.

That's the attack.

No magic.

Just a catastrophic failure at the foundation.

Part 21: What About Dice Rolls?

This is one of the interesting protections COLDCARD already supported.

Users could contribute their own entropy using physical dice.

Conceptually:

So even if:

Device randomness = weak

independent randomness from:

physical dice

can restore unpredictability.

According to COLDCARD's current advisory, if the affected Add Dice Rolls workflow included at least 50 fair, independent, private dice rolls, those rolls contributed at least 128 bits of independent entropy. With 99 or more qualifying rolls, COLDCARD says the dice contributed approximately 256 bits.

The important words are:

fair, independent, private.

Typing:

1
1
1
1
1
1
1
...

is obviously not entropy.

Neither is using dice rolls that an attacker has recorded.

Part 22: What About a BIP-39 Passphrase?

This is different from the COLDCARD PIN.

Your seed might be:

24 words

Then you can add a BIP-39 passphrase:

Every different passphrase generates a different wallet.

So if your underlying seed is weak but the attacker doesn't know a strong, independently chosen passphrase, they have another secret to overcome.

COLDCARD's current guidance says a strong, unique BIP-39 passphrase creates an additional barrier, but explicitly warns that it does not repair the compromised seed itself. Users with affected seeds are still instructed to migrate.

And:

COLDCARD PIN

is not the same thing as:

BIP-39 passphrase

The PIN protects access to the device.

The BIP-39 passphrase changes the wallet cryptographically.

Part 23: Does Updating the Firmware Fix My Wallet?

No.

This may be the single most important practical takeaway.

Suppose vulnerable firmware generated:

OLD SEED

Then you install fixed firmware.

You now have:

Fixed firmware
+
OLD SEED

The seed hasn't magically changed.

Its original randomness is whatever it was when it was created.

The current COLDCARD security status explicitly says the fixed firmware corrects future seed generation but does not repair existing affected seeds.

To fix the underlying problem, you need:

Part 24: Moving the Same Seed to Another Hardware Wallet Doesn't Fix It Either

Suppose you generated the vulnerable seed on a COLDCARD.

Then imported those words into:

Trezor

or:

Ledger

or:

Sparrow

or another device.

You haven't changed:

THE SEED

You've only changed where it is stored.

Block specifically calls this out: an affected seed remains affected after export or migration to another wallet because the weakness belongs to the original seed itself.

Think:

Weak password:

password123

Moving it from:

Laptop A

to:

Laptop B

doesn't turn it into a stronger password.

Part 25: What Is Currently Considered Affected?

As of August 15, 2026, COLDCARD's current security status lists the following minimum fixed releases.

TAPSIGNER, OPENDIME, and SATSCARD use different codebases and are not listed as affected by this issue.

Most importantly:

What matters is the firmware that generated the seed — not simply which firmware is installed today.

Part 26: The Practical Decision Tree

Did COLDCARD itself generate the seed?
             │
        ┌────┴────┐
       NO         YES
       │           │
Imported seed      ▼
isn't weakened   Was it generated
merely because   on affected firmware?
COLDCARD held it      │
                  ┌───┴───┐
                 NO      YES
                 │         │
              Not this     ▼
               issue    Did you add
                        >= 50 fair,
                        independent,
                        PRIVATE dice
                        rolls during
                        generation?
                         │
                    ┌────┴────┐
                   YES        NO /
                    │        unsure
                    ▼          │
             Dice exception    ▼
             may apply       MIGRATE

A strong BIP-39 passphrase may add substantial protection, but COLDCARD's current guidance still says an affected underlying seed should ultimately be replaced.

Part 27: Was This Actually Exploited?

This was not merely a lab curiosity.

Block published its analysis on July 30, 2026, explicitly saying that active exploitation was underway following reports from COLDCARD users.

Bitcoin Optech reported the following day that users had discovered unauthorized transactions from COLDCARD-generated wallets and that estimated losses had already exceeded 1,000 BTC at the time of publication.

Later blockchain analysis from TRM Labs attributed multiple theft waves totaling roughly 1,816 BTC, valued around $116 million at the time of its August 5 report. Because attribution and on-chain clustering can evolve, that figure is better understood as an analyst estimate rather than an immutable final total.

The vulnerability therefore crossed the important line from:

"Someone could theoretically do this."

to:

"Real funds appear to have been stolen
while researchers were investigating it."

Part 28: Why This Vulnerability Is So Interesting

Most people imagine hardware-wallet attacks like this:

This was fundamentally different.

The attack is closer to:

The attacker may never interact with the victim.

May never see the hardware wallet.

May never see the seed phrase.

May never compromise the victim's computer.

May never know the PIN.

They can independently arrive at the same secret.

That is what makes RNG failures so dangerous.

Part 29: A Cybersecurity Analogy

Imagine an application generates API keys.

They're supposed to look like:

7Fr12zRqx7aP9bT8N6L...

The developer assumes:

128 bits of randomness

But someone discovers the keys are actually generated from:

username
+
current timestamp
+
process ID

Then hashed:

SHA256(
    username
    + timestamp
    + process_id
)

The resulting API token looks gorgeous:

9cc5a0f3e41b78...

Long.

Hexadecimal.

SHA-256.

Very cyber.

But an attacker who knows:

username = dan

account created approximately:
3:00–3:05 PM

possible process IDs:
1–65535

doesn't attack SHA-256.

They generate every plausible input:

dan + 3:00:00 + PID1
dan + 3:00:00 + PID2
dan + 3:00:00 + PID3
...

hash each one and test the resulting tokens.

The cryptographic hash function is perfectly secure.

The input entropy was the problem.

That's essentially the category of failure here.

Part 30: Another Way to Think About It

You can reduce the entire vulnerability to one sentence:

A cryptographic secret is only as unpredictable as the process that created it.

Everything downstream can be perfect.

But if the first step was:

Generate predictable secret

then:

                 ┌────────────────────┐
                 │ Predictable secret │
                 └──────────┬─────────┘
                            │
                everything below it
                inherits the problem
                            │
          ┌─────────────────┼─────────────────┐
          ▼                 ▼                 ▼
     private keys       public keys      addresses
          │
          ▼
     signatures

You can't bolt unpredictability onto an already-predictable private key afterward.

The Big Misconceptions

"Attackers guessed all possible 24-word phrases."

No.

They exploited structure in how affected devices generated the underlying randomness.

"They reversed Bitcoin addresses into private keys."

No.

They generated candidate private keys forward and checked whether the resulting addresses matched real blockchain data.

"They hacked the COLDCARD remotely."

Not necessarily.

The vulnerability lives in the generated secret itself.

"The hardware random-number generator broke."

Not exactly.

The published analysis indicates that the intended hardware RNG existed, but an integration/build issue caused wallet generation to reach the wrong software RNG path.

"PRNGs are insecure."

No.

Cryptographically secure PRNGs are used everywhere.

The problem was this generator, this initialization, and this integration path.

"My seed has 24 words, so it must have 256 bits of security."

No.

Twenty-four BIP-39 words can encode 256 bits of source entropy, but only if those underlying bits were actually chosen with that level of unpredictability.

"I updated my firmware, so I'm safe."

Newly generated seeds on fixed firmware use the remediated path.

An old affected seed remains old and affected.

"I moved my seed to another hardware wallet."

Same seed.

Same underlying entropy.

Same problem.

"I had a PIN."

The COLDCARD PIN protects the device.

It doesn't add entropy to the underlying BIP-39 wallet.

"I had a strong BIP-39 passphrase."

That is materially different.

It adds an independent secret an attacker also needs, although COLDCARD still recommends replacing an affected underlying seed.

The Entire Thing in One Diagram

                 WHAT SHOULD HAVE HAPPENED

              Physical hardware entropy
                         │
                         ▼
                       TRNG
                         │
                         ▼
               unpredictable entropy
                         │
                         ▼
                  BIP-39 mnemonic
                         │
                         ▼
                    master key
                         │
                         ▼
                 Bitcoin addresses


===============================================================


                  WHAT WENT WRONG

           device/timing-related state
                        +
           software Yasmarang PRNG
                        +
        limited additional secure entropy
              on later devices
                        │
                        ▼
             random-looking output
                        │
                        ▼
                BIP-39 mnemonic
                        │
                        ▼
                   master key
                        │
                        ▼
                Bitcoin addresses
                        │
                        ▼
               Public blockchain
                        ▲
                        │
                        │
                ATTACKER DOES:
                        │
       recreate plausible RNG conditions
                        │
                        ▼
                 candidate seed
                        │
                        ▼
               candidate address
                        │
                        ▼
           compare against blockchain
                        │
                   ┌────┴────┐
                   │         │
                 match     no match
                   │         │
                   ▼         └──► next candidate
              seed recovered
                   │
                   ▼
                Bitcoin
                 stolen

The Bigger Lesson

There's a tendency in security to focus on impressive cryptography:

AES-256
SHA-256
secp256k1
Secure Elements
HSMs
air gaps

But many catastrophic failures happen in the glue between those technologies.

Configuration.

Build systems.

Random-number generation.

Key initialization.

Library integration.

State handling.

Fallback behavior.

Error handling.

The COLDCARD incident is almost a perfect example.

The interesting question isn't:

"Was Bitcoin's cryptography broken?"

It wasn't.

The interesting question is:

"Did the system actually provide strong randomness to the code that created the secret?"

For affected firmware, the answer was not what everyone thought it was.

Final Cheat Sheet

If You Remember Only Five Things

1. Your seed phrase isn't secure because it contains 24 words.

It's secure because the information encoded by those words is supposed to have been chosen unpredictably.

2. The attacker isn't randomly guessing the entire universe of Bitcoin seeds.

The vulnerability provides structure that can dramatically narrow the candidate space.

3. Bitcoin's public blockchain helps verify candidates.

Candidate seed → candidate address → check blockchain.

4. An air-gapped wallet can't protect you from a secret that another person can independently reconstruct.

The secret never has to physically leave the wallet.

5. Fixing the RNG does not fix old RNG output.

Affected wallets require a newly generated seed and migration, not merely a firmware update.

Sources & Further Reading

The primary technical source for the vulnerability mechanics is Block Bitcoin Engineering and Security's July 30, 2026 analysis, which traces the incorrect RNG integration, deterministic Yasmarang fallback, affected generations, limited 32-bit reseeding on later devices, and candidate-validation attack model.

Coinkite/COLDCARD's technical backgrounder and security advisory provide the manufacturer's explanation of the integration failure, its approximately 40-bit and 72-bit attack-complexity estimates, affected firmware, dice-entropy exception, passphrase guidance, and remediation.

The current COLDCARD Security Status, verified August 15, 2026, contains the latest fixed-release matrix and explicitly distinguishes firmware remediation from seed migration.

The COLDCARD migration guide describes how imported seeds, dice-generated entropy, passphrases, and affected on-device seeds should be treated.

The official BIP-39 specification explains the relationship between initial entropy, checksums, and mnemonic length.

For independent contemporary reporting on the incident, Bitcoin Optech documented active wallet theft and early loss estimates, while TRM Labs later published blockchain analysis covering multiple theft waves.