BTCPay Server Says Hot Wallets Swept on 2.4.1 and Older

Attackers stole Bitcoin and Litecoin from hot wallets on BTCPay Server instances running version 2.4.1 or earlier, the project said in a security incident post on 2 November. It now says how they got in: they “used a different method to exploit the vulnerability fixed in 2.4.2”, the release BTCPay Server put out on 7 August to close an actively exploited flaw.

A hot wallet keeps the keys needed to spend funds on the server itself, which is what made these instances worth attacking. The project’s account marks a shift from the night of the alert, when its founder said the team was still working out how admin access had been gained. The blog post fills that gap and, importantly for operators, redraws the line between safe and unsafe versions.

That line is now 2.4.2, not the newest release. “If you were already running 2.4.2 or later when we issued our warning on 1 November: we have seen no impact from these attacks on those servers,” BTCPay Server wrote. Anyone on 2.4.1 or earlier is treated as at risk, even without a visible theft.

What operators on 2.4.1 or earlier should do now

For those older versions, BTCPay Server does not treat a software update as enough. It recommends “moving to a fresh server with a new wallet, after sweeping any remaining funds from the existing hot wallet”, and says this holds “even if you have not noticed a theft, and also if you updated from one of these versions after the 1 November warning”. Its reasoning is blunt: “updating alone cannot remove access an attacker may already have gained,” and “an unchanged wallet balance does not rule out an earlier attack.”

The recovery steps it lists are to create a new wallet with a new seed on a trusted device and sweep remaining hot-wallet funds into it; take the old server offline while preserving logs; provision a fresh virtual machine and install the latest supported release rather than restoring the old server image onto it; and, from a trusted device, revoke and replace exposed credentials, including hosting, SSH, application, API and Lightning secrets. Reusing the old seed on a new server, it warns, leaves those funds at risk. TSN’s guide to what a seed phrase is and how to keep it safe explains why a seed that may have been exposed should no longer guard money.

One reassurance sits alongside the warnings. “Funds in wallets whose spending keys are held off the server, including hardware wallets, were unaffected by these thefts,” the project said, and it repeated its standing advice to accept payments into wallets of that kind. Operators who need a hot wallet for day-to-day takings are told to keep only working balances on the server and move the rest off it.

How much was taken is not clear

BTCPay Server published two destination addresses named in the incident reports, one Bitcoin and one Litecoin, but was careful about what they prove. “Some activity at these addresses appears to predate the thefts,” it said, and their balances “should not be treated as a confirmed total of losses”. It has not established the full timeline or which transactions are linked, and gives no overall figure for the amount stolen. No count of affected servers has been published either.

The project also offered an unusual admission. “We wish we had done more to reach users still running older versions and alert them to the importance of updating,” it wrote, noting it had shipped several security updates since the August advisory. Victims are asked to email [email protected] with their version and timings, and told never to send seed phrases, private keys or passwords.

A timeline that starts almost three months before the drains

BTCPay Server gives the sequence in UTC, which is the same as London time at this time of year. The fix came first: version 2.4.2 shipped on 7 August, followed by further security releases through to October. The thefts came much later. A wallet drain described in the reports happened at 13:46 on 1 November, though BTCPay says it has “not established when attackers first began exploiting the vulnerability”. The first email reporting a theft arrived at 20:56 that evening. During 1 November the project contacted VPS hosts, including LunaNode, asking them to take instances offline; at 22:25 it warned the community on X and told operators to shut their servers down. On 2 November it published an investigation update naming 2.4.1 and earlier as affected, and this fuller post followed.

Why self-hosted payment servers carry the update burden

BTCPay Server has no central off switch, which is the point of it: each merchant or host runs an independent copy, free of a payment middleman. The flip side showed here. The project’s first move had to be a public plea for every operator to turn their instance off, and hosts stepped in to pull older servers for customers who might never see the warning. When the software is self-run, the timing of each security update rests with the person running the box, and in this case the instances that were hit had, on the project’s account, been left on pre-August code for the best part of three months.

There is a compliance reading for anyone handling customer money this way. A fix being available is not the same as a fix being applied, and regulators increasingly expect the gap between the two to be measured and closed. BTCPay Server’s advice effectively tells operators to assume breach: once a server that held spending keys may have been reached, rebuilding and rotating secrets is safer than trusting that an update has swept the intruder out. Founder Nicolas Dorier put the risk appetite plainly on X, writing that operators should not keep more in a hot wallet than they are ready to lose, because “we can’t guarantee it won’t happen again”. The thinking is the same one that followed the Bloom wallet drain and the far larger Binance security incident, both unrelated to this attack: once someone else holds the keys, the money is gone in minutes.

What BTCPay Server has not yet detailed is the “different method” the attackers used against the already-patched flaw. Until it does, the safest reading of its own guidance is the strict one: on 2.4.1 or older, rebuild rather than patch, and treat every secret the old server touched as burned.

Sources

• BTCPay Server blog: “Security Incident Affecting BTCPay Server 2.4.1 and Earlier”, 2 November 2026
• BTCPay Server on X: alert, 1 November 2026
• BTCPay Server on X: investigation update, 2 November 2026
• Nicolas Dorier on X: hot wallet balances, 2 November 2026
• BTCPay Server blog: Security Advisory, 7 August 2026 (background on the earlier flaw)

Related stories

• Bloom Says Attackers Drained 9,408 SOL From 49 Users’ Wallets
• FBI Names North Korea in $6bn+ Binance Hack as Withdrawals Reopen in Phases
• What Is a Seed Phrase? (And How to Keep It Safe)