BTCPay Server, the open-source software merchants run on their own machines to accept bitcoin, has traced a wave of hot-wallet thefts to instances running version 2.4.1 or older. The project said it has no credible reports of drains on the current 2.4.7 release, about six hours after it told every operator to switch their server off.
How much was taken, how many merchants were hit and exactly how the attacker got in have not been disclosed.
What BTCPay Server has said so far
The first warning came late on Sunday. “We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers,” BTCPay Server said, asking anyone running an instance to stop it with the ./btcpay-down.sh script until the investigation was complete.
Early on Monday the project narrowed the scope. “Our incident response investigation identified an attack vector targeting instances running versions 2.4.1 (Jul 23, 2026) or older,” the team said in its update. It added that it had “no credible reports of hot wallet drains for users running the latest 2.4.7 release” and asked anyone affected to send details and logs to its security address.
In the same thread the team said some hosting providers had shut customer instances down automatically to keep older versions from being exploited, and thanked LunaNode by name. Merchants on a hosted plan who found their checkout offline overnight may find that this is the reason.
Admin access and an older set of bugs
Nicolas Dorier, BTCPay Server’s founder, gave the first details between the two statements. He said the project’s own public servers, which run 2.4.7, were not attacked, and that the reports appeared to involve versions before 2.4.2. “The attacker managed to log in as admin on those instance, we are still trying to figure out how,” Dorier wrote.
Later that night he said there were traces that vulnerabilities fixed in 2.4.2 had been used, and in a reply he said this did not appear to be a new vulnerability. That points back to August. The release notes for version 2.4.2, published on Aug. 7, said it included a “fix of a critical vulnerability that is being actively exploited” and told operators: “You need to update as fast as you can.” The same release fixed a two-factor authentication bypass through Basic authentication on the Greenfield API and switched Basic authentication off by default five minutes after an account is created.
The August incident was not about hot wallets. BTCPay Server’s advisory at the time said the exploited flaw exposed credential files for LND Lightning nodes, that funds were stolen from those nodes, and that on-chain wallets, including hot wallets, were not affected. The project has not said which pre-2.4.2 weakness was used this time, so the link between the two episodes should not be assumed until its promised write-up is published.
Why a hot wallet changes the risk
A BTCPay Server store can receive payments into a watch-only wallet, where the server only holds public keys and the signing keys stay elsewhere. A hot wallet is the opposite: the seed sits on the server so the software can send funds itself, which is convenient for refunds and payouts. Anyone who takes full control of that server can sign a transaction and move the balance, which is what the reports describe.
Dorier has been blunt about that trade-off. He has told users not to keep more in a hot wallet than they are ready to lose. When one user asked whether an affected merchant should treat the seed as compromised, he replied that they should consider the whole server compromised, not just the seed.
The other lesson is patching. Version 2.4.1 shipped on July 23, so a server in the affected range has missed at least six releases and more than three months of fixes, including one that was publicly labelled as actively exploited. Self-hosting removes the custodian from the payment flow, but it also leaves the update schedule to the merchant, and a payment server that runs quietly in the background is easy to forget.
What operators should do now
Dorier said a blog post with more detail is coming and that operators who had updated at least once since 2.4.2 had no reason to panic. He urged users to update often and not to keep too much in a hot wallet.
Based on the project’s statements, merchants still on 2.4.1 or older should keep the instance offline, update to 2.4.7 before bringing it back and send their logs to the BTCPay Server team. Given Dorier’s view that an affected server should be treated as compromised, moving any remaining hot-wallet funds to keys that never touched it is the cautious step. The incident adds to a heavy month for crypto security, after October hack losses reached about $6.5 billion, though the BTCPay sweeps hit individual merchants rather than one large platform.
Still open: the total stolen, the number of servers hit, and whether every drained instance was on 2.4.1 or older.
FAQ
Which BTCPay Server versions are affected?
BTCPay Server said the attack vector it identified targets versions 2.4.1 and older. It has no credible reports of hot-wallet drains on 2.4.7, the latest release.
Are watch-only BTCPay Server wallets at risk?
The reports involve hot wallets, where the seed is stored on the server. BTCPay Server has not reported thefts from watch-only setups, but its first alert told all operators to shut down while it investigated.
How much bitcoin was stolen?
No total has been published. BTCPay Server is collecting reports from affected users and says more detail will follow in a blog post.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
