Coinkite shipped firmware 5.6.1 for the Coldcard Mk4 and Mk5 and 1.5.1Q for the Q model on August 20, 2026. If you own a Coldcard, you need to keep two things apart. The update closes the gap
Coinkite shipped firmware 5.6.1 for the Coldcard Mk4 and Mk5 and 1.5.1Q for the Q model on August 20, 2026. If you own a Coldcard, you need to keep two things apart. The update closes the gap for everything you create from now on. It does not repair a seed that was generated on a faulty release. For that seed, the only remedy is a move to a freshly generated recovery phrase.
The maker says so in plain terms in its notice: “Installing this update does not make an existing vulnerable seed safe.” The status page at coldcard.com/security/status puts it even more briefly: “An update is not a seed migration.”
That means anyone who set up their device between March 2021 and July 2026 and has used the same recovery phrase ever since is affected. In that case the update alone is not enough, not even when the Coldcard shows the new version number afterwards.
The two releases are the result of a three-week review Coinkite began after the emergency update of July 31. They replace releases 5.6.0 and 1.5.0Q, which were pushed out quickly at the time, and they go beyond a plain bug fix.
You can read the release off the file name. The file linked on the download page for the Mk4 and Mk5 is called 2026-08-20T1336-v5.6.1-mk-coldcard.dfu, the one for the Q 2026-08-20T1335-v1.5.1Q-q1-coldcard.dfu. Both carry August 20 as a timestamp in the name itself.
According to the maker, the release covers four areas: seed generation, the checking of transactions before signing, the isolation of data over the USB connection, and the behaviour around backups. Coinkite prefaces the list with a caveat that is strikingly sober in its wording: these are specific controls, not a claim that every conceivable flaw has been ruled out.
The seed is the number from which all of a wallet’s keys and addresses are derived; the twelve or twenty-four words on the emergency sheet are only its readable form. That number is generated once, when the device is set up, and never changed again.
That is exactly where the oddity of this case comes from. A firmware update swaps out the software that generates new seeds. It does not touch the existing seed, because it cannot touch it without destroying the wallet. So anyone who updates an affected device and then keeps using it has repaired the software and kept the weakness.
The incident itself demonstrated this over the summer. Attackers cleared bitcoin balances from devices whose recovery phrase was predictable; we described the first waves and the scale on July 31 in our report on the Coldcard firmware flaw. Accounts of the total damage vary: TRM Labs puts it at around $116 million, while CoinDesk cites around $114 million in its report on the new firmware. The account from crypto.news speaks of 1,816 bitcoin from more than 5,200 addresses and notes that around 90 percent of the balances taken in the confirmed waves have not yet been moved on.
Entropy is the measure of how many different values were actually possible when a seed was generated; the higher it is, the more hopeless brute-forcing becomes. The target value is 128 bits.
That value was not reached on the affected releases. According to the maker, seeds on the Mk4, Mk5 and Q came in at roughly 72 bits. For the older Mk2 and Mk3 models the reported figure is far lower still: crypto.news cites around 40 bits of effective randomness for them. The cause was the same in both cases: the devices drew their randomness not from the hardware component built in for it, but from a software substitute.
What this difference means in practice is hard to capture in a single image, because the scale is deceptive. The gap between 72 and 128 bits is not a surcharge but a shift of many orders of magnitude. What matters for you is the plain consequence: a seed with too little randomness is predictable, and it stays that way for as long as it is in use.
The maker’s migration guide names the affected builds precisely: the Mk2 and Mk3 on releases 4.0.1 through 4.1.9, the Mk4 and Mk5 on the standard track before 5.6.0, the Q before 1.5.0Q, the Edge builds before 6.6.0X and 6.6.0QX respectively. The flaw thus reaches back to March 2021.
The new lock is ready, the old one is still in the door: the corrected firmware changes nothing about a seed that was already generated on the faulty release. The most conspicuous change in the new release concerns setup. On the standard track, a new seed is no longer created from the device’s randomness alone. You have to add randomness yourself, through exactly one of three methods: at least 65 key presses at an unpredictable rhythm, 50 rolls of a real six-sided die, or 128 coin flips.
The device mixes this self-generated share with fresh device randomness. According to the maker’s machine-readable status file, the contribution of both security chips feeds into every seed. Anyone who wants to bypass the device randomness entirely will find the separate “Dice Rolls Only” track for it: it requires 50 rolls for a twelve-word phrase and 99 rolls for a twenty-four-word one.
The effort is deliberate. It shifts part of the trust from the component back to you, and it is the point at which setting up a hardware wallet now feels noticeably different from before. If you have the choice, take the dice method: it is the easiest to follow and can be watched as a process in its own right.
cryptoticker.io ran this survey itself on August 22, 2026. Method: retrieval of the maker’s public download page at coldcard.com/downloads with a browser identifier, followed by a count of every model row listed there, complete with version number and marking. Seven model rows were checked.
The result: five of the seven rows carry the note “Fixed release,” two do not. Those marked are the Mk5/Mk4 with 5.6.1, the Q with 1.5.1Q, the Edge tracks with 6.6.0X and 6.6.0QX, and the shared row for the Mk3 and Mk2 with 4.2.0. Left without the note are two rows the page itself lists as superseded: a standalone Mk4 row with release 5.4.5 and the Mk1 row with 3.0.6.
For Mk1 owners that is the practically relevant finding. The security notice names 4.0.1 as the first affected release, while the Mk1 line ends at 3.0.6 and shows no corrected build. What that means for an Mk1 the page does not say outright.
A second finding concerns the verification date. The status page carries the stamp “Verified 2026-08-17” and at the same time recommends 5.6.1 and 1.5.1Q, two releases that were not shipped until three days later. Whether the page was checked again after the release and only the stamp was not updated is not apparent from it.
A brief additional check concerned language: three German paths of the maker’s addresses were retrieved, and all three responded with 404. The security notice, the status page and the migration guide are available in English only.
What could not be checked was whether the Mk4 row listed as superseded, with 5.4.5, contains the flaw or merely documents a discontinued track. Also not verifiable: how many devices in Germany are affected, how many holders have already installed the update, and whether the maker informs its customers by email in German. The survey only says what the download page displayed on that day.
A release track is the delivery branch on which a firmware is maintained; the same device can carry entirely different version numbers depending on the branch. That is exactly where checks fail when they go by the model name alone.
The maker therefore names minimum versions per branch. For the Mk2 and Mk3, 4.2.0 or newer applies. For the Mk4 and Mk5 on the standard track, 5.6.0 or newer applies; for the Q on the standard track, 1.5.0Q or newer. Anyone on the Edge track needs 6.6.0X on the Mk4 and Mk5, or 6.6.0QX on the Q. As the currently recommended builds it names 5.6.1 and 1.5.1Q on top of that.
In practice that means: open the firmware version display on the device, note it in full including the letter suffix, and compare it with the minimum version for your branch. An “X” or “QX” at the end points to the Edge track, for which different numbers apply.
There is one case in which the maker considers the move unnecessary. Anyone who enriched their seed at the time with their own rolls, through the “Add Dice Rolls” function, may under narrow conditions do without it.
The conditions are set out precisely in the guide: at least 50 fair, mutually independent rolls, entered through that function; the roll sequence must have stayed private and never been written down or disclosed; and the words to be used are those the device displayed after the rolls were added. Under these conditions the maker considers at least 128 bits of additional entropy to have been introduced; from 99 rolls he cites around 256 bits.
The sentence that matters comes at the end: with fewer rolls or under uncertain conditions, migrate. Anyone who, after four years, no longer clearly remembers how many rolls there were and whether the sequence really was never recorded anywhere falls into the migration obligation. Uncertainty does not count as relief here.
The three-week review turned up points that have nothing to do with the original randomness flaw. They concern the path a transfer takes from the computer to the device and back.
A PSBT is a partially signed bitcoin transaction: the file in which the wallet software stores the payment proposal and which the hardware wallet is shown for approval. What is new is that the Coldcard checks this file again immediately before signing and aborts the process with the message “Transaction modified” if anything has changed between display and approval. When handed over via USB, the checksum of the request must additionally match the stored file, or the process ends with “PSBT checksum mismatch.”
SIGHASH_SINGLE is a signature variant that fixes only part of a transaction and leaves the rest open. It will be blocked by default in future. On top of that come tighter limits on data retrieval over USB, which is confined to the result of the running encrypted session, and the requirement that a firmware file match its signed length.
Further changes concern the check under BIP-322, the sealing-off of the delta mode, and the behaviour around backups: a backup captures the wallet currently in effect. In the case of a passphrase wallet it contains that wallet’s derived master key, not the words of the parent seed and not the passphrase.
A BIP-39 passphrase is an additional, freely chosen word or sentence from which, together with the seed, a wallet in its own right emerges. It rightly counts as a strong extra safeguard, and the maker expressly recommends it for any wallet whose loss would genuinely hurt its owner.
For the present flaw it still does not solve the problem. The maker puts it unmistakably: a strong, unique passphrase can make access to the underlying seed harder, but it does not repair it. Users with a passphrase should move as soon as is practicable.
Anyone using a passphrase for a new wallet should back it up separately from the seed, note the fingerprint of the passphrase wallet, and test the recovery before any money goes onto it. What “genuinely hurts” the maker deliberately does not fix as an amount; that is a personal threshold.
Checksum and signature decide whether the downloaded firmware file really comes from the maker. A security incident draws imitators, and a forged firmware file would be the most convenient route to someone’s balances. The maker therefore requires two checks before the file goes onto the memory card.
First, the comparison of the SHA-256 checksum: a checksum is a short fingerprint of a file that changes completely at even the smallest alteration. Second, the check of the signed file signatures.txt, which proves that the file really comes from the maker. Only then follows the installation via the memory card, and after the restart the visual check of the displayed version number.
Download the file only from the maker’s address and never from a forum, a chat or a link someone sent you unasked. And one more ground rule the migration guide repeats specifically: never enter your seed words on a website and never send them to a support channel.
The maker describes two routes. The recommended one runs across two devices, because at no point is a working wallet given up.
If you need to buy a second device for this route, you will find the available models and their differences in our hardware wallet comparison. A device from the same maker is not required: a recovery phrase to the BIP-39 standard can in principle also be loaded onto a device from another brand.
On the second device the corrected firmware is installed and an entirely new seed is generated, expressly not a clone of the old one. Then the backup and the fingerprint of the new wallet are checked. There follows a small test transfer from the old to the new wallet, and only once it has arrived does the rest follow. The old backup is kept until the move is complete.
Anyone with only one device takes the fallback route: first check the backup and the fingerprint of the old seed, then install the corrected firmware, delete the old seed on the device, generate and check the new one, and transfer the balances by alternately loading both seeds. This route is trickier, because for a time it does without a second safeguard.
The guide pulls up three warnings expressly. Never destroy the only working copy of a wallet. Abort and transfer nothing if a fingerprint or an address does not match. And do not use the device’s clone or takeover functions as a solution: they copy the affected seed along with everything else.
The move leads to movements between your own addresses. For each of them, record the time, the transaction ID and the addresses involved, and keep the note together with the rest of your records. It costs five minutes during the move and spares you the later reconstruction from memory when the path of your balances has to be evidenced.
Coinkite lists four external checks on its status page, each with a name, subject and scope. A reviewer with the account @bigshiny0 measured on a real device with Mk4 firmware 5.6.0 that a 32-byte request triggers eight read operations at the hardware random number generator, so the corrected path does indeed reach the component. A second reviewer read the source code across all corrected branches and confirmed that the software substitute had been removed. A third checked the same for the emergency update. A fourth rebuilt release 5.6.0 and compared it byte for byte with the published signed file.
The maker qualifies these proofs himself. The published evidence does not constitute a full independent audit of every corrected firmware file; each only confirms its own scope of review. It is also notable that the checks named refer to 5.6.0, while 5.6.1 is the one currently recommended.
The reckoning is open too. Asked whether the formal technical post-mortem is available, the status page, as of August 15, 2026, answers: no, it is still in progress. Anyone who wants to know how the flaw could go undetected for four years is therefore still waiting.
An assessment, flagged as such: that a maker names the limits of its own evidence this clearly is unusual, and speaks for the account. It does not replace the outstanding report, though, and for the question of whether you go on trusting your device, the post-mortem remains the more important text.
You will find the maker’s notice on the release in the Coinkite blog on releases 5.6.1 and 1.5.1Q, and the step-by-step instructions for the move in the Coldcard migration guide.
(As of August 22, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)
