Coldcard’s Suspected Fourth Attack Wave: Why Are 462 Addresses Still Being Swept?

Galaxy Head of Research Alex Thorn has identified what appears to be a fourth organized wave of Bitcoin theft involving seeds generated by affected Coldcard firmware. During the approximately 2.5-hour period between blocks 960,778 and 960,792, researchers observed 218 transactions involving 462 suspected victim addresses, 216 new destinations, and 388.92748828 BTC. Similar transactions reportedly remained in the mempool, while confirmed transactions had replace-by-fee, or RBF, enabled.

The activity suggests that public disclosure and emergency firmware updates have not eliminated the risk attached to previously generated seeds. The observed sweep rate reached 13.8 per block, compared with 0.3 during a pre-incident control window—an approximately 45-fold increase. Nevertheless, “fourth wave” remains a research classification based on on-chain patterns. The evidence does not conclusively identify the attackers or prove that the same entity conducted every wave.

Key Takeaways

• The suspected fourth wave involved 218 transactions, 462 suspected victim addresses, 216 new destinations, and 388.92748828 BTC.
• The concentration of activity and approximately 45-fold increase in the sweep rate support the interpretation of systematic exploitation rather than ordinary wallet migration.
• Predominantly 1:1 transfers, minimal destination reuse, and second-hop movements may indicate a more dispersed fund-management strategy.
• Updating Coldcard firmware does not repair an existing weak seed; potentially affected users must generate a new seed through a corrected process and migrate their assets.

What Happened During the Suspected Fourth Attack Wave?

According to Thorn’s monitoring, the latest transaction cluster appeared between Bitcoin blocks 960,778 and 960,792. Over approximately 2.5 hours, researchers identified 218 transactions sharing characteristics associated with the continuing Coldcard incident. The transactions involved 462 addresses classified as suspected victim addresses, 216 new destination addresses, and 388.92748828 BTC. Similar transactions were reportedly still awaiting confirmation in the mempool, suggesting that the observed window may not represent the end of the activity.

Previously confirmed transactions also enabled RBF, which allows an unconfirmed Bitcoin transaction to be replaced with a version paying a higher fee. RBF is a normal network feature and does not independently demonstrate malicious intent. In the context of an ongoing mass sweep, however, its use suggests that whoever initiated the transactions was actively managing confirmation priority and could increase fees if competing transactions appeared.

The reported address and value figures require careful interpretation. A “victim address” is an address classified by researchers through its transaction behavior and connection to the relevant Coldcard firmware boundary; it does not necessarily represent one individual user. One wallet may control multiple addresses, and a transaction may spend several inputs. Likewise, the 388.92748828 BTC observed in this window should not automatically be added to earlier loss estimates until researchers confirm that the addresses, inputs, and transferred funds do not overlap with previous clusters.

The most important evidence is the intensity and consistency of the activity. Researchers calculated 13.8 sweeps per block during the monitored period, compared with 0.3 per block in a pre-incident control window. Such a sharp increase is difficult to explain solely as independent users reacting to a security warning. The transactions also reportedly contained no inputs predating the relevant Coldcard firmware boundary, reinforcing the association between the swept funds and seeds created under affected firmware.

Galaxy’s assessment therefore rests on the combined weight of timing, address selection, transaction construction, and destination behavior. No single characteristic is conclusive: legitimate users can enable RBF, generate new receiving addresses, or migrate funds simultaneously after an official warning. The organized-attack interpretation becomes more persuasive when these characteristics appear with unusual regularity across hundreds of firmware-linked addresses.

However, on-chain analysis cannot directly reveal who controls the private keys. One attacker could change transaction strategies between waves, while several operators could independently exploit the same weakness after it became public. Galaxy has consequently treated the clusters as coordinated attack waves without claiming that every wave has been definitively attributed to the same entity.

What Does the New Transaction Topology Reveal?

The suspected fourth wave displayed a predominantly 1:1 structure in which funds from victim addresses were sent to separate new destinations. Only one destination reportedly received two sweeps, and no obvious central aggregation address appeared during the initial monitoring period. Some of the funds subsequently moved to second-hop addresses.

This structure differs from the clearest fingerprints observed earlier in the incident. Galaxy’s analysis found that the first two major waves repeatedly used hardcoded fees of 30 sat/vB and similar batching patterns, supporting the possibility of a shared operator or attack tool. A later wave shifted toward individual transfers and dispersed destinations. Across the first three identified waves, Galaxy-linked reporting placed the affected amount at 1,367.05 BTC from 4,585 addresses, while stressing that differences in transaction fingerprints prevented definitive attribution to a single attacker.

One explanation is that an attacker recognized that centralized collection addresses made earlier transactions easier to cluster and monitor, then adopted new destinations and additional hops to reduce immediate visibility. Another is that disclosure of the weakness enabled copycat attackers to search for remaining vulnerable seeds using independently developed tools. Both interpretations are consistent with the transaction patterns, but neither can be proven from topology alone.

Second-hop transfers should not automatically be described as laundering. They may separate the initial extraction from longer-term custody, prepare funds for later consolidation, test whether addresses have been flagged, or route assets toward external services. Investigators will need to determine whether the second-hop addresses eventually converge or interact with identifiable entities. At this stage, the defensible conclusion is that the latest transactions show systematic sweeping combined with increasingly dispersed fund management.

The evolution of the attacks also changes the practical risk for users. Galaxy identified an initial burst in which 1,082.65 BTC was swept from 1,196 addresses within approximately 41 minutes. Later activity targeted additional addresses and smaller balances using different structures. This may indicate a transition from rapidly extracting visible high-value wallets to continuously scanning the remaining population of weak seeds.

A continuing enumeration campaign can revisit the same vulnerable seed space and target smaller balances as attack tools improve or transaction costs change. Public disclosure may also create a race between legitimate owners attempting to migrate and attackers attempting to reconstruct their keys. The suspected fourth wave is therefore important not merely because of its observed value, but because it indicates that unmigrated seeds may remain exploitable after the most visible initial thefts have ended.

The Technical Root Cause: Predictable Randomness

Block’s Bitcoin Engineering and Security team traced the underlying issue to Coldcard firmware’s integration with its random-number-generation path. According to Block, a configuration intended to disable MicroPython’s hardware-RNG implementation caused an external library to fall back to the deterministic Yasmarang software generator rather than the expected STM32 hardware RNG. The library checked whether a configuration macro existed, but not whether it was enabled.

For affected Mk2 and Mk3 firmware, the fallback generator could be initialized using device metadata and timing state without receiving cryptographically secure entropy through the vulnerable path. If an attacker could determine or sufficiently constrain the device UID, timer state, and previous random-number calls, candidate outputs could potentially be reproduced offline. On later devices, secure-element input was added, but Block reported that only four bytes of the resulting digest reached the reseed function, limiting the securely differentiated state to no more than (2^{32}) possibilities under the relevant assumptions.

Passing weak random output through a cryptographic hash does not solve the problem. A hash can make the results appear uniformly distributed, but it cannot create more possible secrets than existed in the original input space. An attacker can enumerate candidate seeds, derive their Bitcoin addresses, and compare those addresses with the public blockchain. A match provides a validation signal that may reveal the corresponding private key without physical access to the wallet.

This is not a failure of Bitcoin’s signature system or seed standards. The vulnerability concerns the randomness used before the private keys were created. Once a weak seed exists, an offline, air-gapped, or physically secured device cannot prevent another party from reconstructing the same secret through computation.

Block described its report as an early technical assessment published while exploitation appeared to be active and noted that it had not completed empirical testing of every possible attack path. Its findings should therefore be considered alongside Coinkite’s investigation and final technical conclusions. Even with that qualification, the central security issue is clear: protections applied after key generation cannot restore entropy that was absent when the seed was created.

Why Is Updating the Firmware Not Enough?

Coinkite’s official guidance distinguishes between preventing vulnerable seed generation in the future and repairing an existing seed. Fixed firmware changes how new secrets are generated, but it cannot alter a mnemonic created under an affected version. Importing that mnemonic into updated firmware or a different hardware wallet recreates the same private keys and preserves the underlying risk. Complete remediation requires generating a genuinely new seed through a corrected process and transferring the funds on-chain.

Coinkite identifies Mk2 and Mk3 seeds generated on firmware versions 4.0.1 through 4.1.9 as affected. It also advises migration for Mk4 and Mk5 seeds created before standard firmware 5.6.0 or Edge firmware 6.6.0X, as well as Coldcard Q seeds created before standard firmware 1.5.0Q or Edge firmware 6.6.0QX. The company describes the impact on Mk4, Mk5, and Q as less severe than on affected Mk2 and Mk3 devices but still serious. Mk2 and Mk3 owners can generate replacement seeds after installing version 4.2.0 or later.

Genuinely independent entropy may provide limited exceptions. Coinkite states that at least 50 fair, independent, and private dice rolls may contribute 128 bits of entropy, while 99 or more rolls contribute approximately 256 bits. Users who cannot confidently confirm how the rolls were generated and incorporated should not rely on this exception. A strong BIP-39 passphrase may create an additional barrier, but Coinkite still recommends migration because the passphrase does not repair the original seed. A Coldcard PIN is not a BIP-39 passphrase and does not prevent blockchain funds from being moved if the private keys are reconstructed.

What Should Coldcard Users Do Now?

Potentially affected users should determine the device model and the firmware version used when the current seed was originally generated. The current firmware version alone is insufficient if the seed was created on an older Coldcard or imported from another device. Firmware checks and downloads should be conducted only through official Coinkite channels, without following links provided by unsolicited support accounts, social-media messages, or recovery services.

Users within an affected range should install the applicable fixed firmware and generate an entirely new seed. They should securely record the new backup, verify the wallet fingerprint and receiving address directly on the hardware screen, and send a small test transaction before transferring the remaining balance. Restoring the old mnemonic into a new device or continuing to use it after a firmware update does not resolve the vulnerability.

The incident also creates an opportunity for secondary fraud. Users should never disclose seed words, private keys, passphrases, dice-roll sequences, or wallet backups to anyone claiming to represent Coldcard, Coinkite, Galaxy, an exchange, law enforcement, or a recovery company. Legitimate support personnel do not need these secrets to verify firmware or explain migration procedures.

Multisignature users should assess how many affected keys participate in the spending threshold. If enough vulnerable keys can be reconstructed, multisignature protection may also fail. Replacing keys without weakening the threshold or unnecessarily exposing wallet scripts can require a more carefully planned migration, particularly for high-value or institutionally managed wallets.

Broader Implications for Hardware-Wallet Security

The incident does not demonstrate that all hardware wallets or self-custody systems are unsafe. It shows that wallet security depends on the entire key lifecycle: entropy generation, firmware configuration, dependency review, seed backup, transaction verification, and eventual migration. Labels such as “air-gapped,” “offline,” “open source,” or “secure-element protected” describe individual defenses rather than the security of the complete system.

Open-source firmware enables independent review but does not guarantee that implementation errors will be discovered before exploitation. Stronger assurance requires reproducible builds, entropy testing, code review across library boundaries, deterministic test vectors, and fail-closed behavior when secure randomness is unavailable. A wallet can otherwise continue receiving funds and signing valid transactions while concealing a weakness that has existed since seed creation.

The central lesson is one of seed provenance. Moving an old mnemonic to newer hardware improves its storage environment but does not change its mathematical security. Hardware wallets protect how private keys are stored and used; they cannot retroactively make a predictable seed unpredictable.

Conclusion

The suspected fourth Coldcard attack wave indicates that the risk window remains open. The compressed timing, approximately 45-fold increase in the sweep rate, firmware-linked input boundary, and regular transaction structure support Galaxy’s assessment of systematic activity. The attackers’ identities and the relationship among the different waves, however, remain unconfirmed.

For potentially affected users, the priority is to verify when and how their current seed was created. Fixed firmware can protect newly generated secrets, but it cannot repair an existing weak seed. The effective remedy is to generate a new seed through a corrected process and migrate the assets securely.

Risk Disclaimer: This article is for informational purposes only and does not constitute investment, legal, or cybersecurity advice. Users should verify firmware versions and migration procedures through official Coinkite documentation and seek qualified assistance for complex wallet configurations.