COLDCARD weak PRNG put Bitcoin wallet keys at risk

Coinkite has published an urgent advisory about random-number generation in COLDCARD hardware wallets. An integration error across several firmware generations caused secret generation to use the deterministic Yasmarang generator instead of the intended hardware randomness source. This is not a “weak PIN” problem: an attacker may be able to reconstruct a constrained set of seed candidates and validate them against public Bitcoin addresses.

The disclosure coincided with analysis of 1,196 addresses swept in 41 minutes on 30 July. The transactions moved 1,082.65 BTC, valued at roughly $70.2 million at the time. Public researchers have linked that pattern to the COLDCARD defect, but an important limitation remains: no public report has reconstructed a specific victim seed and matched it to a drained address. The theft attribution remains an assessment; the firmware defect and migration requirement are confirmed by the manufacturer.

What failed in the generator

Block Bitcoin Engineering and Security’s analysis traces the fault to a subtle preprocessor distinction. The production configuration defined MICROPY_HW_ENABLE_RNG as 0 because COLDCARD supplied its own hardware-RNG wrapper. Libngu checked only whether the macro was defined, not whether its value enabled the feature.

The call therefore resolved to MicroPython’s software Yasmarang generator. Its state was initialized from values including a chip identifier and timing registers. These are fixed or constrainable inputs, not fresh cryptographic entropy, and the generator collected no new randomness after initialization.

For Mk2/Mk3 v4 firmware, the stream is deterministic once UID, timing and call history are fixed. Later Mk4, Q and Mk5 devices added secure-element material, but only four digest bytes reached reseed(). That gives at most 2^32 securely distinguished variants for a fixed fallback state. Hashing the result cannot recreate missing entropy.

Which seeds need attention

The decisive factor is the firmware used when the secret was created, not the version installed today or the device’s purchase date. Coinkite’s advisory lists these fixed releases:

Model and track	Fixed release
Mk2/Mk3	4.2.0 or later
Mk4/Mk5 standard	5.6.0 or later
Q standard	1.5.0Q or later
Mk4/Mk5 Edge	6.6.0X or later
Q Edge	6.6.0QX or later

Coinkite identifies seeds generated on Mk2/Mk3 4.0.1–4.1.9, Mk4/Mk5 before the fixed releases and Q before the fixed releases. Block’s source analysis also includes Mk2/Mk3 4.0.0. If the generation history is uncertain, use the wider range and migrate.

TAPSIGNER, OPENDIME and SATSCARD use different codebases and are not affected by this defect.

Updating does not repair an old seed

This is the key operational lesson. Firmware corrects future generation. It cannot add entropy to existing BIP-39 words. Restoring an old seed into updated firmware or another wallet carries the weakness forward.

A safe response should be structured as follows:

1. Confirm the model, update track and current firmware version.
2. Install the fixed release from the official source and verify the version on the device screen.
3. Create a new seed after updating, record its backup, and verify both its fingerprint and receive address on the COLDCARD display.
4. Send and confirm a small test transaction.
5. Only then move the remaining funds. Retain the old backup until migration is fully confirmed, then treat it as a retired secret.

Do not migrate under pressure from a private message, advertisement or supposed support agent. The disclosure creates an immediate phishing opportunity. A seed, dice sequence or passphrase must never be entered into a website or revealed to anyone offering help.

Dice, passphrases and multisig

Coinkite says at least 50 fair, independent and private dice rolls added during generation contributed at least 128 bits of independent entropy. If the number or privacy of those rolls is uncertain, the recommendation remains migration.

A strong, unique BIP-39 passphrase creates a separate wallet that seed words alone cannot reach. The manufacturer still recommends replacing the seed; short, patterned or reused phrases may be guessed. The passphrase is not the device PIN.

Multisig limits exposure only when the quorum is not composed entirely of keys generated on affected devices. Three wallets of the same type do not provide implementation independence if all share the same generation defect.

What organisations and custody teams should do

• inventory devices, firmware histories and the origin of every active key;
• identify seeds created in the affected window, including seeds later imported elsewhere;
• use an approved, two-person migration runbook with a test transaction;
• verify that multisig arrangements use independent implementations and entropy sources;
• monitor retired addresses and retain evidence of versions, fingerprints and transactions;
• train asset owners to recognise fake updates and seed-recovery requests.

For corporate keys, RNG failure is an asset-governance and evidence problem, not only a device problem. Apply the lifecycle principles in our secrets management and rotation guide and connect them to a rehearsed incident-response plan.

Primary facts versus Breachroad analysis

Coinkite confirms the affected releases, fixed firmware and requirement to generate a replacement seed. Block explains the technical mechanism and state-space bounds while noting that it has not completed an end-to-end empirical exploit test for every scenario. The large transfer is visible on the public blockchain; attribution to recovered COLDCARD seeds has not been publicly proven.

Breachroad’s conclusion is to migrate every seed with uncertain provenance under a controlled process and to design multisig for implementation independence. Cybersecurity training for technical and finance teams can rehearse secret-safe migration, while an IT security audit can assess custody, access, evidence and response procedures.