BTCPay Server ties hot-wallet thefts to versions 2.4.1 and older

What did BTCPay announce? Late on Sunday the project posted on x.com that it was "receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers" and asked everyone running an instance to shut it down. Its timeline puts the first reported drain at 13:46 UTC on Nov. 1, the first theft email at 20:56 UTC and the public warning at 22:25 UTC.

Is this a new bug? Not quite. BTCPay says the attackers used a different method to exploit the vulnerability it patched in 2.4.2 on Aug. 7. That August flaw exposed credentials for LND Lightning nodes. This time the targets were on-chain hot wallets, which keep their spending keys on the internet-facing server. Founder Nicolas Dorier said the attacker had logged in to affected servers with administrator access, according to decrypt.co.

How much was stolen? Nobody has said. BTCPay has not disclosed how many servers were hit or how much was taken. It published one Bitcoin and one Litecoin address named in incident reports, but warned that some activity there predates the thefts, so the balances are not a confirmed loss total.

Did hosting companies step in? Yes. BTCPay asked VPS providers to take instances offline as a precaution, and LunaNode and others did so.

I run 2.4.1 or older. Is updating enough? No, according to BTCPay. It tells these operators to sweep any remaining hot-wallet funds into a new wallet made with a new seed on a trusted device, take the old server offline after saving logs, and install the latest release on a fresh virtual machine. That applies even if no theft is visible, because "an unchanged wallet balance does not rule out an earlier attack," and to anyone who upgraded only after the Nov. 1 warning.

What about passwords and keys? Hosting, SSH, API and Lightning credentials the old server could reach should be revoked and replaced from a trusted device, never typed into the old machine.

Were hardware wallets hit? No. Wallets whose spending keys live off the server, including hardware wallets, were unaffected, and BTCPay still recommends taking payments into them. Hardware devices have had their own scares this autumn, from the Keystone breach to a reported implant in a Trezor Safe 5, but here the off-server key was the protection. Unlike the exchange and protocol cases behind most losses to hacks, there is no central operator here: each merchant decides when to install a patch.

Where do victims report? BTCPay asks them to email security@btcpayserver.org with the version they ran, when they last updated and the relevant transaction IDs, and to file a police report. It warns never to send seed phrases or private keys.