BTCPay Server Hot Wallets Drained on Outdated Self-Hosted Instances

Attackers stole Bitcoin and Litecoin from hot wallets on outdated self-hosted BTCPay Server instances, exploiting an August flaw in a new way. Operators must rebuild.
BTCPay Server logo overtop bronze abstract cyber background

Attackers stole Bitcoin and Litecoin from hot wallets on self-hosted BTCPay Server instances on November 1, 2026, prompting the open-source payment processor to tell operators to shut their servers down. The project said the attacks targeted servers running version 2.4.1 or earlier, using a new method to exploit a vulnerability it fixed in August.

BTCPay Server is free software that merchants run on their own machines to accept Bitcoin and other cryptocurrency payments. A hot wallet keeps the keys needed to spend funds on the server itself.

How the drains unfolded

In its incident report, BTCPay laid out a timeline in UTC. A wallet drain described in the reports took place at 13:46 UTC (8:46 AM ET) on November 1. The project received its first email reporting a theft at 20:56 UTC (3:56 PM ET).

BTCPay then contacted VPS hosting providers, including LunaNode, and asked them to take BTCPay Server instances offline as a precaution. At 22:25 UTC (5:25 PM ET), the project warned on X that hot wallets were “being swept by unauthorized attackers” and asked operators to run ./btcpay-down.sh until the investigation was complete.

Founder Nicolas Dorier said in a follow-up post that the attacker “managed to log in as admin” on the affected instances, and that the project’s own public servers running 2.4.7 were not attacked. BTCPay developer Andrew Camilleri said the evidence showed the attacker scanning the internet for instances and trying to break in “in batches.”

Early on November 2, BTCPay said its investigation had found an attack vector aimed at 2.4.1 and older, and that it had no credible reports of hot wallet drains on 2.4.7, the latest release. It also thanked LunaNode and other hosts for shutting down older instances quickly.

An August flaw exploited a second way

Version 2.4.2 shipped on August 7, 2026, with a fix for a critical vulnerability. BTCPay’s August advisory said the bug could let an unauthenticated remote attacker obtain .macaroon credential files for LND, a Lightning Network node. The project confirmed at the time that attackers had exploited it and that funds were stolen. That advisory said the attacks it reviewed targeted only LND credentials and that on-chain hot wallets were not affected.

The November thefts hit those on-chain hot wallets. BTCPay said the attackers used “a different method” to exploit the same vulnerability. It has not published technical details of the new method, and it said it has not established when attackers first began exploiting it.

The project has shipped several more security updates since August, including 2.4.4 and 2.4.5, before 2.4.7 arrived on October 29. “We wish we had done more to reach users still running older versions and alert them to the importance of updating,” BTCPay wrote. It also pointed to “the rise in automated attacks using AI” as a reason to install updates quickly.

Losses remain unconfirmed

BTCPay has not disclosed a total loss figure or the number of affected merchants. It published one Bitcoin address and one Litecoin address identified in the incident reports, but warned that some activity at those addresses appears to predate the thefts. The project said their balances “should not be treated as a confirmed total of losses.”

Funds in wallets whose spending keys are held off the server, including hardware wallets, were not affected, according to BTCPay.

What BTCPay operators should do now

Operators can check their version at the bottom of the page after logging in. BTCPay said it has seen no impact on servers that were already running 2.4.2 or later when it issued its November 1 warning.

For anyone on 2.4.1 or earlier, BTCPay strongly recommends moving to a fresh server, even if no theft was noticed and even if they updated after the warning. Camilleri put it plainly: “updating after the fact is not enough.” BTCPay’s recovery steps are:

  • Sweep the hot wallet. Create a new wallet on a trusted device with a new seed and move any remaining funds into it. Reusing the old seed leaves funds at risk.
  • Take the old server offline. Preserve logs and transaction records for the investigation first.
  • Build a fresh virtual machine. Install the latest supported release from trusted sources and connect the new wallet. Do not restore the old server onto the new machine.
  • Rotate exposed credentials. From a trusted device, replace hosting, SSH, application, API and Lightning credentials the old server could reach. Never enter new credentials on the old machine.

Victims can report incidents to security@btcpayserver.org with their version, timeline and public transaction IDs, and should also report thefts to local authorities. BTCPay stressed that no one should ever send seed phrases, private keys or passwords.

Hot wallets keep drawing attackers

The BTCPay thefts land days after the $6.3 billion Binance hot wallet theft, the largest crypto theft on record. Other recent cases include Polymarket traders losing $2.7 million after a third-party script compromise and Bitcoin Depot’s $3.6 million Bitcoin theft after a credential compromise.

This time, attackers went after many small merchant servers that had gone unpatched for months. Dorier’s advice to merchants was direct: “Don’t put more than you are ready to lose in hot wallet.” BTCPay recommends keeping only operating funds on the server and accepting payments into wallets whose keys live elsewhere.

Picture of m00s3c

m00s3c

Moose (@m00s3c) is the author of BreachNews, focusing on data breach intelligence, dark web monitoring, and threat analysis. His work involves analyzing breach claims, reviewing leaked datasets, and tracking threat actor activity to provide clear, factual reporting.

Latest News

BREACHNEWS.COM/SUPPORT/

Support Independent News.

Help support breach monitoring, investigations, infrastructure, and reporting.

Support the site →