Coldcard PRNG Flaw: Weak Randomness and Bitcoin Theft

What is the Coldcard flaw?

According to Block, which analyzed the firmware, an integration error made seed generation use MicroPython's deterministic fallback generator (Yasmarang) instead of the STM32 microcontroller's hardware generator. Per The Hacker News, the error dates to March 2021: a build configuration and a library that checked whether a macro existed rather than whether it was enabled bound the device to the fallback generator, seeded from the chip's unique ID and timer registers, with no fresh entropy.

Coinkite estimates the entropy at about 40 bits for the Mk3 and about 72 bits for the Mk4, Mk5 and Q, against 128 bits for a 12-word BIP-39 seed. A space this small can be searched offline: the attacker generates candidate seeds, derives their addresses and compares them with the public blockchain, which acts as an oracle.

Which devices and versions are affected?

• Mk2 and Mk3: firmware 4.0.1 to 4.1.9; fixed in 4.2.0 or later.
• Mk4 and Mk5: before 5.6.0 (standard) or before 6.6.0X (Edge); fixed in 5.6.0 or 6.6.0X.
• Q: before 1.5.0Q (standard) or 6.6.0QX (Edge); fixed in 1.5.0Q or 6.6.0QX.

Exposure depends on the firmware used when the seed was created, not the version installed today. TAPSIGNER, OPENDIME and SATSCARD are not affected.

How did the attack unfold?

On July 30, 2026, an attacker drained 1,196 addresses in 41 minutes. Galaxy Research mapped the transactions and places the attack about 30 hours before Coinkite's public disclosure. Chainalysis says about 30 million dollars were taken in the first ten minutes and that the attacker appeared to have studied the wallets beforehand. Two more suspected waves were identified on August 1; Galaxy has not confirmed that all the addresses come from weak entropy. Block reported the issue to Coinkite on July 30.

What guidance does Coinkite give?

Verify your backup, install the fixed firmware, generate a new seed, verify the address on the device, send a small test transaction, then move the rest and keep the old backup until confirmed. A seed supplemented with at least 50 fair, independent and private dice rolls is not considered exposed by this bug alone. A long, unique BIP-39 passphrase makes the attack harder without removing the need to migrate. This guidance concerns device owners; it is not financial advice.

How do you detect and test a randomness defect in your products?

1. Inventory everything your product generates: API keys, session tokens, reset links, signing keys, invitation identifiers.
2. Spot non-cryptographic sources: Math.random(), clock-seeded generators, version 1 UUIDs, counters.
3. Test entropy: generate a large sample, check for duplicates and patterns, and check that a restart does not reproduce the same sequence.
4. Add a startup test that fails if the randomness source returns abnormal output, because a dependency or configuration update can swap the source without any noise.

How do you fix it?

Use the system's cryptographic generator (crypto.randomBytes, secrets, getrandom) with at least 128 bits of entropy for a secret, and 256 bits for a durable key. A fix does not retroactively repair existing secrets: rotate everything generated during the vulnerability window. Rate-limit validation endpoints, which serve as oracles.

What changes when an AI agent has access to secret generation?

Agents create secrets more often than one thinks: they write code that generates tokens, provision API keys, create service accounts and, more and more, wallets for automated payments. Three agent-specific risks. Generated code: a coding assistant can produce a token generator using Math.random() or a time-based seed; the defect passes tests because the output looks random. The model as a randomness source: a large language model is not a cryptographic generator, and an instruction such as "generate a random key" can yield predictable values; randomness must come from a system tool, never from model text. And key custody: an agent holding a signing key or a recovery phrase in its context can be led to disclose it through prompt injection (OWASP LLM01, LLM02), and a weak key makes the theft unnecessary, since the attacker can simply recompute it.

Useful controls: secret generation by an audited system function, secrets kept out of the model's context, amount ceilings and human approval for any payment action, and rotation after any incident. See AI agent security and API keys in Git history.

What should you check on an agent with the Coldcard randomness flaw?

An agent red team checks where the secrets the agent creates come from, what it does with them, what it can sign or spend and what booby-trapped content makes it reveal. In five days for 1,900 euros, the Agent Red Team Express looks at what an agent does with keys generated with weak randomness. The method details the approach.

What is the lesson?

The difference between a secret and a public value comes down to the randomness source. Verify it at runtime and not only at integration, treat public ledgers as oracles and rotate secrets as soon as a generation flaw is known.