BTCPay Server 2.4.1 and earlier: hot wallets drained, move to a fresh server

BTCPay Server, the self-hosted Bitcoin payment processor, is dealing with a second wave of thefts in three months. On 1 November 2026 the project began receiving reports that Bitcoin and Litecoin had been drained from hot wallets on servers running BTCPay Server 2.4.1 or earlier, and it told operators to take affected machines offline. The project's own incident page says servers on 2.4.2 or later showed no impact, but that anyone on 2.4.1 or older should move to a fresh server rather than simply update. No CVE number, loss total or exploit method has been published yet.

Key points

• BTCPay Server 2.4.1 (released 23 July 2026) and earlier are affected, according to the project's incident page.
• The project received its first theft report on 1 November at 20:56 UTC and warned the community on X at 22:25 UTC.
• The project recommends moving 2.4.1-or-older installations to a freshly built server with a new wallet seed, not just updating in place.
• The project says it saw no impact on servers that were on 2.4.2 or later at the time of the 1 November warning.
• No CVE ID, exploit details or total amount stolen has been published as of 2 November.

What to do

1. Check your version. Log in to BTCPay Server and look at the bottom of the page.
2. If you run 2.4.1 or earlier, the project says to move to a fresh server even if you have noticed no theft. Create a new wallet with a new seed on a trusted device, sweep the remaining hot-wallet funds into it, and do not reuse the old seed.
3. Take the old server offline after preserving logs and transaction records. Provision a fresh VM, install the latest supported release from trusted sources, and connect the new wallet. Do not restore the old server onto the new machine.
4. Replace credentials from a trusted device: hosting account, SSH, application, API and Lightning credentials. Do not type new credentials into the old machine.
5. If you saw a theft or unauthorised access, the project says to treat the whole machine and its secrets as compromised, even if you have updated since.
6. If you are on 2.4.2 or later, keep updating. BleepingComputer reports that the fixed release for the latest emergency update is 2.4.7 and that you can update from Server Settings, then Maintenance, then Update; Docker installs use ./btcpay-update.sh from the btcpayserver-docker folder. The project's incident page, which we read, does not mention 2.4.7, so check your own version page against the project's current release notes.
7. Report losses to security@btcpayserver.org with your BTCPay version, update dates, when you noticed the incident (with time zone) and relevant transaction IDs and addresses, and to local authorities. The project says never to send seed phrases, private keys or passwords.

What happened

The project's incident page gives this timeline, all in UTC. A wallet drain occurred on 1 November at 13:46, although the start of exploitation is unknown. The first theft report arrived by email at 20:56. Hosting providers, including LunaNode, were asked to take BTCPay instances offline as a precaution, and at 22:25 the community was warned on X and operators were asked to shut their servers down. On 2 November an investigation update identified 2.4.1 and earlier as the affected range.

The page says Bitcoin and Litecoin were stolen from hot wallets, meaning wallets whose spending keys live on the server itself. It lists one Bitcoin and one Litecoin destination address, and cautions that some activity at those addresses appears to predate the reported thefts, so balances there should not be read as confirmed losses. It does not give an amount stolen.

BleepingComputer, which reported the story on 2 November, adds that the attacker logged in as an administrator on instances running older versions, and that the project does not describe the attacks as targeting public servers. We could not confirm the administrator-login detail on the project's own page, so treat it as that outlet's account. BleepingComputer also says the project began receiving theft reports on the evening before its Monday update.

The page says funds held in wallets whose spending keys are kept off the server, such as hardware wallets, were unaffected. Its advice is to keep only operational funds in a hot wallet.

Background

This is not the first incident this year. On 7 August 2026 the project published a security advisory for BTCPay Server 2.4.2. It described a critical flaw that let an unauthenticated remote attacker obtain .macaroon credential files for LND, the Lightning Network node software, and so take control of an LND node and move funds. The advisory said only LND deployments carried that credential risk, that BTCPay's on-chain wallets, including hot wallets, were not affected by it, and that attackers had exploited the flaw and stolen funds. Version 2.4.2 upgraded LND to 0.21.1 and regenerated the macaroons automatically. It also removed public access to the LND API on Docker deployments for the time being, which stopped external wallets such as Zeus from connecting through the BTCPay domain or onion address.

CoinDesk reported the August episode on 8 August, naming the hardware-wallet maker Foundation and a project called Citadel21 among victims whose Lightning nodes were swept; Foundation's CEO said the on-chain hot wallet was untouched. The advisory credited Craig Raw for responsible disclosure, with Team Red (OpenSats) helping analyse the exploit. A follow-up post on 10 August set a recovery bounty of 10 percent of the amount recovered, up to 3 BTC.

The November incident is different in what was drained: hot wallets rather than Lightning nodes. The project's incident page also says the attackers used a different method to exploit the vulnerability that 2.4.2 had fixed. We have not seen the technical details behind that statement, and the project had promised a full postmortem "in the coming days" in the advisory it updated on 2 November.

The incident page notes that further security updates were published between August and October, naming 2.4.4 and 2.4.5. BleepingComputer adds that on 29 October the project disclosed a critical vulnerability found with Anthropic's Frontier OSS scanner and released 2.4.7 as an emergency update, and that the project reports no credible hot-wallet drains on 2.4.7. We could only verify that last statement through BleepingComputer, not through the project's pages we opened.

How the risk works

Self-hosting a payment processor means the operator, not a vendor, is responsible for patching. A BTCPay hot wallet is convenient because the server can sign payouts and refunds on its own, but that means anyone who gains administrative control of the server can spend whatever sits in it. That is why the project's guidance does not stop at "update". A server that was compromised before the patch can keep leaking after the patch: stolen administrator sessions, SSH keys, API keys and wallet seeds stay valid until someone replaces them. The incident page's instruction to build a fresh machine, generate a new seed and rotate every credential from a trusted device follows from that.

The same logic explains the advice about hardware wallets. A wallet whose spending keys never reach the server cannot be drained by taking over the server, and the project says wallets with off-server spending keys were unaffected in this incident.

What it means

For merchants who accept Bitcoin or Litecoin through a self-hosted BTCPay Server, the practical message is that "running the latest version today" is not enough if the server was exposed on an older version. Anyone who ran 2.4.1 or earlier at any point after July, and cannot rule out that someone logged in, should treat the wallet seed as burned. Hosting providers that run BTCPay for customers have already been asked to take instances offline, so some users may find their servers unavailable until the operator has rebuilt them.

For the wider ecosystem, it is the second exploited BTCPay incident since August, within a project whose users tend to be small merchants with no security team. The August episode hit LND; November hit hot wallets. Whether the two share a root cause is something the project has not said in the pages we read, and we do not claim they do.

What we don't know yet

• The vulnerability. No CVE ID, affected component or exploit method has been published, and the project has said it is withholding technical details while operators patch.
• How much was stolen. The incident page gives no total, and warns that earlier activity at the listed addresses makes balances unreliable as a loss figure.
• When it started. The project says the start of exploitation is unknown; the first confirmed drain it lists is 1 November 13:46 UTC.
• Whether 2.4.2 to 2.4.6 are fully safe. The project says it saw no impact on 2.4.2 or later at the time of its warning, while BleepingComputer's account centres on 2.4.7. We could not reconcile the two from the pages we opened.
• The relationship to the August flaw and the 29 October emergency update.

What to watch next

Watch the BTCPay Server blog for the promised postmortem, a CVE assignment and any change to the recommended version. Check the BTCPay Server release notes before relying on any single version number in this article, because the sources we read name 2.4.2 and 2.4.7 for different purposes. Operators who use a hosting provider should check whether their instance was taken offline and what the provider needs from them.

Sources

• BTCPay Server: security incident, 2.4.1 and earlier (primary source)
• BTCPay Server: security advisory for 2.4.2
• BTCPay Server: security incident, our response and next steps
• BleepingComputer: BTCPay Server warns of hot wallet thefts targeting outdated instances
• CoinDesk: Another Bitcoin infrastructure exploit hits, this time draining Lightning payment servers