BTCPay wallet thefts: older servers need a recovery plan beyond updating

BTCPay Server operators who were still running version 2.4.1 or earlier when the project issued its November 1 warning should prepare to rebuild their server, even if they subsequently installed an update. The project's November 2 incident report describes thefts from Bitcoin and Litecoin hot wallets and recommends a fresh machine, a new wallet and replacement credentials for affected older installations.

That is a more demanding response than checking that the software now displays the latest version. A patch can close a route into a machine; it cannot establish what happened while that route was open. For a payment server, that distinction reaches beyond the application into the keys that authorize spending.

The version you ran before the warning matters

The maintainers identify 2.4.1 and earlier as the versions targeted in this incident. They report no observed impact from these attacks on servers already running 2.4.2 or later when the warning was issued. That statement describes the investigation's findings, rather than a guarantee against every possible compromise.

The history helps explain why old advice can be misleading. BTCPay's August advisory concerned a vulnerability fixed in 2.4.2 and a then-observed attack against LND credentials. Its assessment of that attack excluded BTCPay's own on-chain hot wallets. The November report describes a different way of exploiting the previously fixed vulnerability. Operators should follow the current incident guidance rather than carry forward the narrower August assessment.

Meanwhile, version 2.4.7, released October 29, contains further security and reliability work. Its fixes include payment permissions, invoice access and authentication handling. Updating to the latest supported release remains necessary, but a current version number is only one part of recovery.

Why the wallet arrangement changes the damage

A hot wallet keeps the material needed to authorize transactions on the server. That allows convenient automated spending, but also makes a compromised payment application a potential route to funds. The project's wallet documentation describes alternatives in which transactions are signed using a hardware wallet or another wallet supporting partially signed Bitcoin transactions.

With that arrangement, preparing a payment and authorizing it are separate operations. A server can assemble transaction information without possessing the private key that completes the signature. BTCPay says wallets with spending keys held off the server were unaffected by these thefts. It still recommends rebuilding exposed older servers: protecting the signing key does not protect every other secret or service on the machine.

This is also why a healthy-looking balance provides an incomplete answer. A merchant's immediate concern is understandably missing money, but the administrator also has to establish whether access credentials remain under their control. Those are different investigations.

Recovery starts outside the old machine

The current recovery guidance calls for moving remaining hot-wallet funds to a newly created wallet using a trusted device, taking the old server offline while preserving relevant evidence, and installing a supported release on a fresh virtual machine. Potentially exposed credentials must be replaced from a trusted environment. Restoring the whole old server would carry its uncertainty into the replacement.

Keep transaction records and the version history available for the incident response team; never send seed phrases or private keys in a support report. BTCPay also cautions against treating the balances of reported destination addresses as a confirmed loss total, because the full relationship between those transactions and this incident has not been established.

For merchants, the practical dividing line is control over spending. Keeping only operational funds in a necessary hot wallet limits what that server can put at risk. A successful recovery should restore a working checkout and establish which machine, which credentials and which keys are trusted to operate it.