{"id":70087,"date":"2026-08-08T21:41:40","date_gmt":"2026-08-08T18:41:40","guid":{"rendered":"https:\/\/lwallet.com.ua\/?p=70087"},"modified":"2026-08-15T18:43:54","modified_gmt":"2026-08-15T15:43:54","slug":"how-coldcard-was-hacked","status":"publish","type":"post","link":"https:\/\/lwallet.com.ua\/en\/how-coldcard-was-hacked\/","title":{"rendered":"How Coldcard Was Hacked \u2014 and Why a Firmware Update Won\u2019t Fix Your Seed"},"content":{"rendered":"\r\n\r\n\r\n

On July 30, 2026, a series of thefts began from Bitcoin wallets whose seeds had been created on vulnerable versions of Coldcard firmware. During the first major incident, 1,082.65 BTC was drained from 1,196 addresses in just 41 minutes<\/strong>. The attackers did not need physical access to a Coldcard, phishing, or a transaction signed by the owner.<\/p>\r\n\r\n\r\n\r\n

The cause was a firmware integration bug: when creating a wallet, the code called a software pseudorandom generator from MicroPython instead of the STM32 hardware random number generator it was supposed to use. As a result, seeds created by the built-in generator on affected firmware versions could contain far less entropy than a properly generated seed should.<\/p>\r\n\r\n\r\n\r\n

Below, we explain what happened to Coldcard, which firmware versions were affected, why simply updating the device does not fix an already generated seed, and how to move funds safely to a new wallet.<\/p>\r\n\r\n\r\n

[vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] Does this affect you?<\/strong> If your seed was generated directly on a Coldcard and you cannot reliably determine the firmware version or how that seed was created, the official COLDCARD Migration Guide<\/a> recommends migrating to a new seed. A seed that was securely generated on another device or by another trusted method and only later imported into Coldcard is not weakened by this bug. But if the seed was originally generated on an affected Coldcard, it remains affected even after recovery, import, or cloning. We explain the separate exception for 50+ independent private dice rolls below. [\/vc_message]<\/p>\n\r\n\r\n\r\n

How Coldcard was compromised: what happened on July 30<\/h2>\r\n\r\n\r\n
\r\n
\"Block<\/figure>\r\n<\/div>\r\n\r\n\r\n

The first major incident: 1,082.65 BTC in 41 minutes<\/h3>\r\n\r\n\r\n\r\n

Galaxy Research<\/a> traced a group of similar transactions made on July 30 between 01:10:20 and 01:51:26 UTC. During that period, funds were moved out of 1,196 Bitcoin addresses, for a total of 1,082.65 BTC \u2014 roughly $70.2 million at the time<\/strong>.<\/p>\r\n\r\n\r\n\r\n

The transactions shared several distinctive traits, including the same unusually high fee of 30 sat\/vB and a similar structure. Those patterns helped researchers separate related transfers from normal network activity and estimate the scale of the attack.<\/p>\r\n\r\n\r\n\r\n

Physical access to a Coldcard is not required for this type of attack. Candidate seeds can be tested offline, Bitcoin addresses can be derived from them, and those addresses can then be checked against addresses already visible on the blockchain.<\/p>\r\n\r\n\r\n\r\n

The attacks continued<\/h3>\r\n\r\n\r\n\r\n

More clusters of thefts appeared after the first incident. On July 31, Galaxy identified another 76.16 BTC taken from 1,478 addresses. The next major incident, which ran from July 31 into August 1, added roughly 208 BTC from 1,912 addresses.<\/p>\r\n\r\n\r\n\r\n

In its updates, Galaxy refers to the largest groups of related transactions as \u201cwaves,\u201d while tracking smaller clusters and other attack traces separately. In other words, this was not simply four individual transfers, but a series of thefts linked to the same vulnerability.<\/p>\r\n\r\n\r\n\r\n

According to Galaxy Research\u2019s August 14 update<\/a>, thefts totaling 1,778.84 BTC from more than 8,600 addresses \u2014 about $112.7 million<\/strong> had been confirmed with high confidence. Including medium-confidence incidents and a fourth large transaction cluster that had not yet been fully confirmed, the estimate could rise to 2,417.35 BTC \u2014 around $153 million<\/strong>.<\/p>\r\n\r\n\r\n\r\n

Galaxy had not identified any new confirmed attacks after August 6, but that does not mean affected seeds became safe<\/strong>. Researchers explicitly warned that thefts could resume and advised owners of single-sig wallets whose seed was generated on an affected Coldcard to move funds to a fresh seed as soon as possible<\/a>.<\/p>\r\n\r\n\r\n\r\n

Researchers also concluded that the vulnerability was likely being exploited by more than one attacker. The final loss figure may still change as additional victims continue to report affected addresses.<\/p>\r\n\r\n\r\n\r\n

If your funds have already been stolen<\/h3>\r\n\r\n\r\n\r\n

As of August 14, of at least 1,778 stolen BTC, around 1,531 BTC remained unmoved at addresses controlled by the attackers<\/strong>, while roughly 246 BTC had already been moved. Galaxy Research said it was in direct contact with 190 victims.<\/p>\r\n\r\n\r\n\r\n

If you have already lost funds, do not throw away your Coldcard or destroy old backups. Coinkite specifically asks users to keep affected devices<\/a>, because they may be useful in a future investigation or potential recovery process. Keep the affected addresses, transaction IDs (TXIDs), and any other wallet information that does not expose private keys.<\/p>\r\n\r\n\r\n\r\n

What Coinkite did<\/h3>\r\n\r\n\r\n\r\n

Rodolfo Novak (NVK) publicly took responsibility for the firmware bug and apologized to affected users<\/a>. Coinkite published an official security advisory<\/a>, then released fixed firmware for every affected model and a separate step-by-step migration guide<\/a>.<\/p>\r\n\r\n\r\n\r\n

After confirming the issue, the company stopped shipments and destroyed remaining Coldcard inventory manufactured with vulnerable firmware<\/a>, while its team began working directly with customers who needed help migrating. TAPSIGNER, OPENDIME, and SATSCARD were not affected by this specific bug because they use a different codebase.<\/p>\r\n\r\n\r\n\r\n

The incident is not fully closed, however. On the current COLDCARD Security Status<\/a> page, Coinkite states that a formal technical postmortem is still being prepared<\/strong>. The generation fix is already available, but the full explanation of how the bug passed earlier reviews and what processes the company will change has not yet been published.<\/p>\r\n\r\n\r\n\r\n

What went wrong with Coldcard seed generation<\/h2>\r\n\r\n\r\n
\r\n
\"Coldcard<\/figure>\r\n<\/div>\r\n\r\n\r\n

How a seed should be generated<\/h3>\r\n\r\n\r\n\r\n

Every new Bitcoin wallet starts with a random number that should be practically impossible to predict. In BIP-39, a 12-word recovery phrase is based on 128 bits of initial entropy, while a 24-word phrase is based on 256 bits. The words shown to the user are simply a convenient way to record that secret.<\/p>\r\n\r\n\r\n\r\n

That is why the length of a recovery phrase is only part of the story. What also matters is how unpredictable the underlying data was when the phrase was created<\/strong>. If the generator can produce far fewer possible outputs, an attacker no longer has to search the full theoretical BIP-39 space.<\/p>\r\n\r\n\r\n\r\n

What went wrong<\/h3>\r\n\r\n\r\n\r\n

In March 2021, Coldcard changed part of the code responsible for obtaining random data during wallet creation. As Coinkite explains in its own technical backgrounder on the incident<\/a>, an integration bug caused the call that was supposed to use the STM32 hardware generator to bind instead to MicroPython\u2019s Yasmarang software generator.<\/p>\r\n\r\n\r\n\r\n

The hardware random number generator did not \u201cfail\u201d while the device was running. The bug happened at firmware build time: the RNG call was linked to the wrong function implementation, while the build still completed without an error.<\/p>\r\n\r\n\r\n\r\n

Block\u2019s technical report traces the vulnerable path back to code introduced in v4.0.0 in March 2021. Coinkite\u2019s current user guidance, however, defines the affected Mk2\/Mk3 range as 4.0.1\u20134.1.9<\/strong>. That current matrix is the one users should follow when checking their wallet and planning a migration.<\/p>\r\n\r\n\r\n\r\n

Why this made seeds guessable<\/h3>\r\n\r\n\r\n\r\n

Yasmarang is a deterministic software generator: if its initial state can be reproduced, it will produce the same sequence of values. In Coldcard, that state depended on the microcontroller identifier and timing-related device values. Those inputs can make a search harder, but they are not a proper cryptographic source of randomness.<\/p>\r\n\r\n\r\n\r\n

On Mk2 and Mk3, no separate cryptographic source of randomness was added to those values. On Mk4, Mk5, and Q, data from secure elements was added during startup, but because of the way reseeding was implemented, only 32 bits of that value affected the software generator\u2019s state. That dramatically reduced the number of possibilities an attacker had to test.<\/p>\r\n\r\n\r\n\r\n

Coinkite estimates an effective search space of roughly 40 bits for Mk2\/Mk3 and around 72 bits for Mk4, Mk5, and Q. That is far below what properly generated BIP-39 entropy should provide. Block separately cautions that practical attack difficulty depends on how much an attacker knows about a specific device and when the seed was generated. So these figures should not be read as a fixed number of attempts required for every wallet.<\/p>\r\n\r\n\r\n\r\n

Once an attacker has a candidate seed, no interaction with the Coldcard is required. Bitcoin addresses can be derived from that seed and compared against public blockchain data. If the addresses match, the attacker has the correct key material and can sign a transaction independently.<\/p>\r\n\r\n\r\n\r\n

Why a firmware update does not fix an existing seed<\/h3>\r\n\r\n\r\n\r\n

Fixed firmware changes how Coldcard generates a seed after the update. It cannot change a seed that was already created on vulnerable firmware.<\/strong> If that seed still controls funds, you need to create an entirely new wallet with a new seed and move the Bitcoin to the new wallet.<\/p>\r\n\r\n\r\n\r\n

Restoring the same recovery words on a Trezor, BitBox, another Coldcard, or a software wallet does not solve the problem. You are restoring the same secret and the same set of keys that may already be easier to recover through brute force.<\/p>\r\n\r\n\r\n

[vc_message color=”warning” message_box_style=”classic” message_box_color=”alert-warning” style=”rounded”] If your seed was generated on affected Coldcard firmware, do not reuse the same recovery words as the basis of a \u201cnew\u201d wallet. First create a fresh seed on fixed firmware or on another trusted device, verify the receiving address, and only then move your funds. [\/vc_message]<\/p>\n\r\n\r\n\r\n

Who is affected by the Coldcard vulnerability<\/h2>\r\n\r\n\r\n
\r\n
\"Coldcard<\/figure>\r\n<\/div>\r\n\r\n\r\n

The key factor is not just the model you own, but the firmware version that was running when the specific seed was generated<\/strong>. Updating a Coldcard today is not enough if the wallet itself was created earlier on vulnerable firmware.<\/p>\r\n\r\n\r\n\r\n

\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n
Model<\/strong><\/th>\r\nFirmware when the seed was generated<\/strong><\/th>\r\nStatus<\/strong><\/th>\r\n<\/tr>\r\n<\/thead>\r\n
Mk1<\/td>\r\nall released versions through v3.0.6<\/td>\r\nnot affected by this regression<\/td>\r\n<\/tr>\r\n
Mk2, Mk3<\/td>\r\nthrough v3.2.2<\/td>\r\nnot affected by this regression<\/td>\r\n<\/tr>\r\n
Mk2, Mk3<\/td>\r\nv4.0.1 \u2014 v4.1.9<\/td>\r\naffected versions<\/td>\r\n<\/tr>\r\n
Mk4, Mk5<\/td>\r\nbefore v5.6.0 on Standard or before v6.6.0X on Edge<\/td>\r\naffected versions<\/td>\r\n<\/tr>\r\n
Q<\/td>\r\nbefore v1.5.0Q on Standard or before v6.6.0QX on Edge<\/td>\r\naffected versions<\/td>\r\n<\/tr>\r\n<\/tbody>\r\n<\/table>\r\n<\/figure>\r\n\r\n\r\n\r\n

Which firmware versions are fixed<\/h3>\r\n\r\n\r\n\r\n