BTCPay Server is advising merchants who ran certain older versions of its open-source payment software to move to a fresh machine and a new wallet after reported Bitcoin and Litecoin thefts. The project’s November 2 incident report says attackers targeted servers running version 2.4.1 or earlier. It says it has seen no impact from these attacks on servers that were already running version 2.4.2 or later when its November 1 warning was issued.
The operational distinction is crucial. A merchant who is potentially compromised cannot assume that installing the newest release makes an existing wallet safe again. BTCPay warns that an attacker could retain credentials or wallet secrets copied before the update. It therefore recommends moving remaining hot-wallet funds using a newly generated seed and rebuilding the affected installation on a clean virtual machine.
The older release boundary matters
BTCPay said the reported attacks targeted version 2.4.1, released on July 23, 2026, and earlier. Version 2.4.2, released on August 7, fixed the underlying vulnerability. The latest release at the time of the incident is 2.4.7, dated October 29, and the project recommends staying current with security updates.
The maintainers also said attackers used a different method to exploit the vulnerability fixed in August. That is an important qualification: the present theft reports should not be simplified into a claim that a brand-new vulnerability exists in the current release. The project states it has no evidence from these attacks affecting servers that were already patched before the warning.
Why hot wallets change the risk
BTCPay allows businesses to accept cryptocurrency without a centralized payment processor holding the funds. A hot wallet, however, keeps spending keys on an internet-connected server so the system can send transactions. If an attacker gains sufficient control of that server, the wallet can be emptied without the business authorizing each transfer.
Keys held off-server work differently. BTCPay says funds in wallets using external spending keys, including hardware wallets, were not affected by these thefts. Receiving payments to a wallet with keys isolated from the server remains the project’s preferred setup. But a merchant who used an affected old version should still rebuild the server, even if funds were stored externally, because other credentials and system secrets may have been exposed.
What BTCPay is telling affected operators to do
The published recovery procedure is more than a restart: generate a new wallet and move any remaining hot-wallet balance from a trusted device; take the old server offline while preserving relevant logs; create a new virtual machine; install a current official release; and rotate passwords, SSH, API, hosting and applicable Lightning credentials. BTCPay warns against cloning the old machine or reusing the old wallet seed.
That advice also applies to merchants who updated only after the November 1 warning, because the update does not prove that attackers had never accessed the old environment. A merchant who suspects theft should treat the complete machine as potentially compromised, not just the cryptocurrency application.
The known timeline is incomplete
BTCPay says it received its first theft report by email on November 1 at 20:56 UTC, warned the wider community later that evening, and asked some hosting providers to take instances offline. The project published affected-version findings on November 2. It has not established when the attackers first began exploiting the vulnerability or a final total of stolen funds.
Investigators can examine destination addresses and transaction histories, but the project explicitly cautions that not every payment to a reported address should be counted as part of the incident. A third-party tracing estimate should not be substituted for an official loss figure.
The lesson is incident response, not just patching
For a merchant, the difference between ‘vulnerability fixed’ and ‘environment clean’ can determine whether funds remain safe. The former means software no longer permits a known attack. The latter requires confidence that an attacker no longer has keys, sessions or access. BTCPay’s unusually direct rebuild guidance is a useful example of why those are different milestones.
Primary sources and verification
BTCPay Server, official incident report and recovery instructions, 2 November 2026
BTCPay Server, official GitHub release 2.4.7
BleepingComputer, incident coverage, 2 November 2026
Suggested Optimisus internal links
Core Lightning’s Viral Shutdown Advice Was Not Official Guidance
