Coldcard suspected fourth attack results in 389 BTC loss

Storing a cold wallet in a drawer doesn't mean the risk is locked away too.

A suspected fourth-wave attack on Coldcard, labeled "Galaxy’s Thorn," has compromised 389 bitcoins. While the number is striking, what’s more alarming is not the scale of the loss itself, but the familiar sequence of operations used by cold storage users: purchasing the device, initializing it, backing up the mnemonic phrase, verifying addresses, and signing transactions. This process was long considered secure—yet now it may have been breached at what appeared to be an ordinary step.

Information available at this stage remains limited: this is a “suspected” attack involving 389 bitcoins, described as the fourth wave associated with Coldcard. The entry point, affected components, and responsibility have not yet been established as a complete, independently verifiable chain.

This should not be used as a reason to dismiss risks; rather, it calls for market restraint. Security incidents are most concerning when met with two types of reactions: one is immediately declaring a product compromised upon seeing a brand name; the other is dismissing anomalies as isolated user errors because technical details have not yet been disclosed. Misattributing blame itself can lead to the next round of losses.

Attackers don’t need to break every layer of defense. Once a user loses judgment at a critical step, concepts like offline signing, hardware isolation, and self-custodied private keys quickly revert to practical concerns: Where did the device come from? Has the firmware been properly verified? Who asked you to confirm the receiving address on the screen? Has the recovery process been compromised?

"The fourth wave" and "389 bitcoins" are the two most striking labels associated with this incident.

The fourth wave means it was not described as an isolated anomaly; the 389 bitcoins transformed the abstract debate over wallet security into a tangible exposure of assets. However, these two labels alone are insufficient to determine the attack’s success rate, the number of victims, or to directly prove that a specific vulnerability has been confirmed.

All we can say for now is that a specific quantity of bitcoins has been involved in what appears to be an attack.

For ordinary coin holders, the risk is not just about whether the private key is connected to the internet. Moving an asset from static storage to an on-chain transfer typically involves multiple steps: device acquisition, initialization, backup, address verification, transaction construction, signature confirmation, and broadcasting. If any step is compromised—through replacement, deception, or forgery—the user may sign a transaction they do not truly understand, even when the device appears to be functioning normally.

This is also where hardware wallets are most commonly misunderstood. They reduce the likelihood of private keys being exposed to online environments, but they cannot automatically detect fake devices, deceptive prompts, fraudulent updates, or transactions with subtly altered recipient addresses. Cold wallets can isolate keys, but they cannot protect users from blind trust in external information.

Institutions face greater challenges.

Trading platforms, custodial service providers, and market makers do not simplify wallet security to merely “whether a device is reliable.” Instead, they must reassess their entire orchestration system: whether withdrawal whitelists are sufficiently strict, whether address changes require multi-party approval, whether multisig participants are truly isolated, and whether suspicious transactions can be delayed for manual review.

The device is like a door lock, but the fund allocation rules are the building’s fire safety system. While a faulty lock is dangerous, the absence of a fire safety system can turn a localized incident into a systemic loss.

What you're buying when you purchase a hardware wallet isn't just a device—it's self-custody of your assets: your private keys are never handed over to a platform, transactions don't rely on centralized accounts, and signatures are completed in an isolated environment.

The cost is also straightforward: the responsibility for verification is returned to the user.

Has the packaging been tampered with? Is the initialization prompt trustworthy? Should the recovery information be re-entered on a specific page? Is the firmware update coming from the correct source? Does the address displayed on the device screen match your expectation? These were once considered minor details of user experience, but now fall squarely within the security boundary.

Manufacturers are caught in a difficult tug-of-war. The product team wants shorter processes and fewer prompts, as complex operations can deter new users; the security team, on the other hand, typically seeks to add more verification steps, restrict high-risk behaviors, and strengthen upgrades and supply chain reviews. Users find these measures inconvenient—and it’s precisely this inconvenience that attackers most exploit.

Neither the platform nor service providers have an easy option. Withdrawal limits, cooling periods for address changes, and manual review of large transfers may be perceived by some users as interference with their autonomy; yet fully shifting the risk to individuals can rapidly erode trust after an incident occurs. From a regulatory perspective, the outlook is even more stringent: if a suspected ongoing attack escalates, issues such as adequate risk disclosure, traceable sales channels, and clear incident notification mechanisms will become unavoidable concerns.

There is no romanticized narrative of “decentralization versus centralization” here. What’s at stake is who bears the cost of verification. Users want low friction, vendors want clear liability boundaries, platforms want auditability, and regulators want traceability. Everyone wants to shoulder less responsibility—and attack vectors often grow precisely at these intersections.

Whether Bitcoin experiences short-term volatility cannot answer the security question for coin holders. More meaningful is monitoring subsequent disclosures of events and whether your operational environment shows any anomalies.

First, determine whether attribution can be traced from "suspected" to a verifiable attack chain. Is the entry point the device, the supply chain, the usage process, or the transaction confirmation stage? The answer dictates entirely different protective measures. Blaming all risks broadly on a single product only leaves the true vulnerability exposed.

Next, consider whether operational procedures may need to be adjusted. If subsequent recommendations require users to re-verify payment addresses, isolate old and new devices, or suspend certain initialization or upgrade processes, the scope of the risk may have already exceeded individual addresses or isolated users. If the risk is only associated with a small number of high-risk behaviors, it is essential to clearly define boundaries as soon as possible to prevent panic from driving legitimate users toward more dangerous “emergency actions.”

Now consider whether large holders are moving away from reliance on a single device. Mechanisms such as multisignature, independent backups, address whitelisting, transaction delays, and decentralized purchasing are valuable not because they make the process appear more professional, but because they ensure that any single mistake does not immediately result in an irreversible loss. A single device can be an important line of defense, but it should not be the sole point of trust.

Finally, watch for small anomalies in your account and signing environment: unfamiliar addresses, unexplained transaction drafts, sudden device alerts, pages asking you to re-enter recovery information, or instructions urging you to bypass verification under the guise of an “urgent upgrade.”

The most dangerous moment in a security incident is often not the day the vulnerability details are disclosed, but the moment users, driven by anxiety, rush their actions and skip verification steps.

The suspected fourth wave of Coldcard attacks involves 389 bitcoins; at this stage, there is insufficient evidence to draw strong conclusions about the specific technical causes or responsibility.

It is enough to compel users to ask a different question: When security is entrusted to a specific device or brand label, are users overlooking the longer chain of operational, informational, and procedural risks behind asset control?

Cold storage has not become obsolete; it remains an essential tool for reducing online exposure. However, it has never been a pass to bypass verification. What users can truly control are questions like: Is the device source trustworthy? Are transactions verified individually? Are backups isolated? Could a single point of failure lead to the total loss of assets?

What needs to be seen next is not more fear-based narratives, but clear attribution of the attack, well-defined operational adjustments, and whether wallet management processes are beginning to make multi-factor authentication and transaction delays the default. Owning the private key is only the first step—controlling the authentication process determines who the private key ultimately signs for.