Anyone running BTCPay Server should check their installation now. Overnight into November 2, 2026, the open-source project reported that attackers had emptied the hot wallets on several self-hosted instances. According to the investigation so far, the affected servers were running outdated software, specifically version 2.4.1 from July 23, 2026, or older. The project says it has no credible reports of drained funds on the current release, 2.4.7.
How many merchants are affected and how much bitcoin was taken is still unknown. The team has not yet published technical details about the attack path either, and a detailed blog post has been announced. Until then, everything that is known comes from posts on X by the project and its founder, Nicolas Dorier.
What happened at BTCPay Server
The project raised the alarm on November 1 at 22:25 UTC. In a post on X, it said it was receiving reports of hot wallets on BTCPay Servers being “swept” by unauthorized attackers, meaning emptied in one go. Anyone running an instance should shut it down with ./btcpay-down.sh until the investigation was complete. At that point the team named neither versions nor amounts.
About two hours later, around 00:30 UTC, Dorier added first findings. The project’s own public servers, which run version 2.4.7, had not been attacked. The reports appeared to involve versions older than 2.4.2. The attacker had logged in as an administrator on the affected instances, and how they obtained that access was still unclear.
Around 02:00 UTC, Dorier wrote that there were traces of pre-2.4.2 vulnerabilities being exploited, and that it did not look like a new flaw. At 04:07 UTC came the most concrete statement from the project so far: its incident response investigation had identified an attack vector targeting instances running version 2.4.1 or older. There were no credible reports of drained hot wallets among users of the latest 2.4.7 release.
Some hosting providers apparently shut down older instances automatically after the first warning. The project explicitly thanked LunaNode and other hosts. If you run BTCPay Server through such a provider and suddenly find your instance offline, check with them first.
Why hot wallets are especially exposed
BTCPay Server is a self-hosted payment processor. Merchants use it to receive bitcoin directly into their own wallet, without a payment provider in between. Optionally, they can set up a hot wallet. In that case, the seed phrase, the secret required to spend coins, is stored on the server itself. That is convenient, for example for automated refunds and payouts, because the server can sign transactions without a separate device.
The price is simple: whoever takes over the server can move the funds. That is exactly the scenario Dorier describes. With admin access to an instance that holds a hot wallet, an attacker has everything they need. Merchants who only use a watch-only wallet and sign with a hardware wallet or offline do not face this specific risk, because no key sits on the server.
Dorier was blunt about the lesson. Do not keep more in a hot wallet than you are prepared to lose, he wrote, because the project cannot guarantee this will not happen again. Asked by a user whether affected operators only needed to replace the seed, he replied that they should consider the whole server compromised.
Background: an August flaw and a string of security releases
BTCPay Server already went through a serious incident in August. Version 2.4.2, released on August 7, fixed a critical flaw that was being actively exploited, according to the project’s security advisory at the time. An unauthenticated attacker could obtain credential files (macaroons) for LND Lightning nodes and use them to move funds. BTCPay Server’s on-chain wallets, including hot wallets, were not affected by that issue, the project said.
Whether the current attack path is related to that flaw is not known. The project only refers to pre-2.4.2 vulnerabilities and to a vector against version 2.4.1 and older. We are not drawing a connection the team has not drawn itself.
Since August, the project has shipped several security updates in quick succession. Version 2.4.5 on October 6 blocks outbound connections to private networks by default to prevent SSRF attacks, among other changes. Version 2.4.6 followed on October 26. The current version 2.4.7 from October 29 fixes 85 findings from an automated code scan by Anthropic, according to its release notes: one critical, 13 high, 52 medium and 19 low. The project has not said whether any of them relate to the current attacks. Dorier stresses that the affected systems were running much older versions.
What is still unknown about the attack
- Scale: Neither the number of affected instances nor the size of the losses is known.
- Technique: The project has not published how the attacker obtained admin rights. Details are expected in the announced blog post.
- Versions in between: The project names 2.4.1 and older as the target of the vector. Dorier also wrote that after reviewing all reports, nobody running a version above 2.4.2 had been affected. There is no formal statement covering each intermediate release.
- Attribution: Dorier published the attacker’s receiving addresses, including one on Litecoin. No group has been named.
The incident follows other recent attacks on infrastructure around crypto payments, such as the DNS hijacking of several DeFi websites. The difference here is that every BTCPay Server merchant is responsible for their own server. There is no central switch the project could flip to protect all instances at once, which is why it had to ask every operator to shut down themselves.
What BTCPay Server operators should do now
- Check your version: The installed version is shown in the footer of the admin area. Anything below 2.4.7 should be updated; on standard installations via Server Settings, Maintenance, Update.
- If you ran 2.4.1 or older with a hot wallet: Treat the server as compromised. Move any remaining funds, ideally from a clean device, to a new wallet with a new seed phrase, not to a wallet whose seed was stored on the old server.
- Review access: Check the list of users and administrators, API keys and connected services. Remove unknown accounts and keys, and renew passwords and two-factor settings.
- Rebuild instead of patching: If you find signs of an unknown admin login, rebuild the instance and preserve logs first. The project asks affected users to send information and logs to its security team.
- Keep the hot wallet small: Only leave as much on the server as operations really require. Larger amounts belong in a wallet whose keys never touch an internet-facing server.
- Update regularly: Dorier explicitly recommends frequent updates. Anyone who has updated at least once since 2.4.2 has no reason to panic, he said.
The recent Electrum wallet vulnerability in version 4.8.3 was another reminder of how much updates matter for wallet software. And last week’s Binance hack showed that hot wallets are the preferred target even at the largest exchanges.
Our take
The incident is painful, but it is not evidence that bitcoin or self-hosted payment processing is fundamentally insecure. Based on what is known, it hits servers that have not been updated in roughly three months, during a period in which the project released several security versions. Self-hosting also means self-patching. If you put a server holding key material on the internet, you have to maintain it consistently. It remains to be seen whether the project’s announced report names further affected versions or a different entry point. Until then: update, review access and keep hot wallets small.
