Three weeks ago, we disclosed a seed-generation failure exploited by hackers in an attack that caused some customers to experience severe financial losses. This release reflects three weeks of sustained review since our July 31 hotfix — including AI-assisted review by Kimi and other frontier models — not just the RNG path, but the whole system.
This update covers what we found, what we fixed, and what customers need to do.
Immediately, we strongly recommend that all COLDCARD Mk4, Mk5, and Q users upgrade to firmware 5.6.1 for Mk4/Mk5 and 1.5.1Q for Q from our official firmware downloads page .
We are grateful to the security researchers who went above and beyond over the past weeks, reporting issues, reproducing edge cases, and reviewing our fixes. Their work put this firmware under intense, sustained scrutiny and made this release stronger.
Law enforcement authorities continue investigating the thefts and are working to identify those responsible. We remain available to assist, and authorities are keeping us informed of material developments.
We’ll keep publishing concrete, inspectable changes as this work proceeds, and we remain committed to supporting every customer working through their migration until it’s done.
This release includes improvements unrelated to the original RNG issue, including policy changes to seed generation, transaction review, USB data handling, firmware-update validation, Delta Mode hardening, and wallet backups.
We’re publishing the major security and correctness changes here, including changes unrelated to the original bug.
Important seed reminder: Installing this update does not make an existing vulnerable seed safe. If your seed may have been generated on affected firmware from 2021 through July 2026, create a new seed using fixed firmware and move your funds by following our seed-generation advisory .
The July 31 firmware corrected the seed-generation failure for new seeds. This release gives affected customers a more thoroughly reviewed foundation to generate replacement seeds and complete their migration. It does not change the migration guidance for seeds already generated on affected firmware.
Our team remains heads down helping affected users complete their migrations. Support and other channels are handling unusually high volumes, so responses may take longer than usual. We appreciate your patience and will continue publishing verified guidance on the Security Status page .
Every newly generated seed now requires one user-sourced entropy method: at least 65 key presses with unpredictable timing, 50 rolls of a physical six-sided die, or 128 physical coin flips. The same requirement applies to generated Temporary Seeds and generated CCC Key C. The standard workflow combines that input with fresh device entropy from all sources available to us: SE1, SE2, and TRNG. The backup PRNG generator now uses SHA-256 Hash_DRBG instead of Yasmarang.
At boot, it is initialized from the STM32 TRNG and reseeded with a full 256-bit digest from SE1 and SE2; its output is also mixed with fresh STM32 TRNG words. For each new seed, firmware combines 32 bytes from the generator, 32 fresh bytes from SE1, and 8 fresh bytes from SE2, then applies double SHA-256 before mixing the required user input with versioned method and purpose identifiers.
Dice Rolls Only remains a separate advanced option: it excludes all hardware-generated randomness and requires 50 rolls for 12 words or 99 rolls for 24 words. Keep every input and any final hash shown by the device private.
Seed-entry handling was also tightened: holding a key no longer counts as repeated dice rolls.
For a wallet intended to hold a meaningful balance, we recommend the standard Dice Rolls option executed honestly with genuine rolls, a strong and unique BIP-39 passphrase, and, where appropriate, a carefully designed multisig setup suited to your threat model.
These protections do not make an already vulnerable seed safe and do not replace moving funds to a newly generated seed.
We made the hardware TRNG path itself more robust against some internal error states and compilation errors:
These controls verify specific source and failure boundaries. Passing the boot-time check confirms that the running build’s rng_get() call reached the intended hardware-read path during the self-test. It does not independently prove the quality of every output or every entropy source, and it should not be read as a claim that finite testing can prove arbitrary randomness.
“FreeZ Agent” reported the staged-PSBT issue, “Rety” reported the Seed XOR issue, and Peter Todd shared ideas on inter-key timing entropy.
We’ve launched a new public COLDCARD Security Status page . This is the place to check the current fixed-release matrix, migration guidance, independent-validation evidence and its stated limits, and verified incident updates. It also provides machine-readable status , and we’ll keep it updated as verified information changes.
Our Security & Transparency hub connects that live status page with the advisory, disclosure history, firmware-verification resources, private reporting instructions, and related public records.
Full technical notes, affected-version information, source links, and researcher acknowledgements are available in our firmware release notes .
Security reports can be submitted privately to [email protected] under our responsible-disclosure policy . The firmware repository now also publishes private reporting guidance in SECURITY.md . Customers who need assistance should our support team .
The full story
This article is one source in a clustered incident — the cluster page carries the summary, timeline and every other outlet covering it.
