On November 1, BTCPay Server told everyone running its software to shut it down. Attackers were sweeping Bitcoin and Litecoin out of hot wallets on self‑hosted instances. By the next day the team had narrowed it to servers still on version 2.4.1, released July 23, or older, and said the attackers had used a different method to exploit the vulnerability it patched in August.

BTCPay Server is free, open‑source software that lets a business accept Bitcoin without a payment processor. In October 2020, when Nigerian banks froze the Feminist Coalition's accounts during the End SARS protests, the group raised about 3.14 BTC in two days through a BTCPay Server that the Human Rights Foundation's Alex Gladstein helped set up. Each operator runs the software on their own server and holds their own keys. That independence is the point, and it is also why nobody could switch the affected servers off for them.

Here is what happened, who was hit, what the team has confirmed so far and what every operator should do today.

What Happened on BTCPay Servers

BTCPay Server Hot Wallets Drained on Outdated Instances: What to Do Now — photo

BTCPay's own timeline, all times UTC, starts at 13:46 on November 1, when a wallet drain described in the incident reports took place. The first email reporting a theft reached the team at 20:56. It contacted VPS hosting providers, including LunaNode, and asked them to take BTCPay instances offline as a precaution.

At 22:25 it posted the public alert: reports of hot wallets being swept by unauthorized attackers, and a request that anyone running an instance shut it down with ./btcpay‑down.sh until the investigation was complete. The alert named no version, no loss figure and no fix.

About two hours later, founder Nicolas Dorier added that the reports appeared to involve releases older than 2.4.2, that the attacker had logged in as an administrator on the affected servers, and that the team did not yet know how. The project's own public servers, running 2.4.7, were not attacked.

Early on November 2, the project said its incident response had identified an attack vector targeting instances on version 2.4.1 or older. It had no credible reports of drains on 2.4.7, the current release. LunaNode and other hosting providers had taken instances offline. Affected operators were asked to send details and logs to security@btcpayserver.org. Later that day BTCPay published a full incident post on its blog.

A hot wallet is the reason the sweeps worked. BTCPay can store a wallet's seed on the server so it signs transactions on its own, which is convenient for refunds and payouts. The documentation marks the option with a danger label. Whoever controls the server as an administrator controls the money. Operators who kept their keys on a hardware device and gave the server only a watch‑only wallet had nothing for the attacker to sign with.

How Much Was Taken

BTCPay Server has not published a loss total or a count of affected merchants. Its incident post lists two destination addresses identified in the reports it received, one Bitcoin and one Litecoin, and warns that some activity at those addresses predates the reported thefts. It has not established the full timeline or which transactions belong to this incident, so the balances there should not be read as a confirmed total.

The only figures so far are third‑party. Bitquery, a blockchain data firm, traced the flagged addresses, and Crypto News Flash reported its findings. As of 06:00 UTC on November 2, Bitquery counted 682 sweeps worth about $1.63 million: 18.38 BTC and 3,405 LTC. The first traced sweep was on October 30, two days before the public alert. Most of the value, 87 percent, left in a single eight‑hour window on November 1. Another 267 sweeps worth roughly $150,000 came after the alert went out.

Bitquery's October 30 start date also sits oddly against BTCPay's own timeline, which puts the first drain in its reports at 13:46 on November 1 and says it has not established when exploitation began. Treat the Bitquery numbers as the best available picture of scale, not as BTCPay's figures.

What BTCPay Says Caused It

BTCPay's incident post says the attackers used a different method to exploit the vulnerability fixed in 2.4.2 on August 7. It has not published technical details of that method, and it says it has not established when attackers first began exploiting it. It adds that it wishes it had done more to reach users still running older versions. Founder Nicolas Dorier said a more detailed blog post is coming.

That vulnerability is the one from August. On August 7, BTCPay Server published a security advisory for a critical flaw that was already being exploited. It let an unauthenticated remote attacker download .macaroon credential files for LND, a Lightning implementation. With those files an attacker could take control of the node and move its funds. Hardware wallet maker Foundation and the Bitcoin zine Citadel21 both reported their Lightning nodes drained that day. The advisory was explicit that BTCPay's on‑chain wallets, including hot wallets, were not affected by that flaw.

The 2.4.2 release notes list two security changes, both reported by the Bitcoin Red Team: a fix for a two‑factor authentication bypass through the Greenfield API's basic authentication, and a change that disables that basic authentication by default five minutes after an account is created. So the November sweeps hit a different target, on‑chain hot wallets, through an admin login that reused what 2.4.2 closed. Which part the attackers reused, and how, is what the promised post should answer.

The timing has also caused confusion. Version 2.4.7 shipped on October 29, one day before the first traced sweep. It fixed 85 security findings reported by Anthropic's OSS Scanner program: one critical, 13 high, 52 medium and 19 low. BTCPay has not linked the sweeps to any of those findings, and the affected servers were several versions behind 2.4.7 anyway.

What BTCPay Server Says Now

The blanket shutdown order has been replaced by version‑specific guidance in the incident post. Anyone already on 2.4.2 or later when the November 1 warning went out: BTCPay has seen no impact on those servers.

Anyone on 2.4.1 or earlier: move to a fresh server with a new wallet, even with no sign of theft, and even if you updated after the warning. Funds in wallets whose keys were held off the server, including hardware wallets, were unaffected. Dorier put it more plainly: for those who updated at least once since 2.4.2, "there is no reason to panic".

Update often, and do not keep too much in a hot wallet. Businesses including Coincards took their installations offline after the first alert.

The project has not published a loss total, a count of affected servers, or technical details of the method. That is the second incident in three months. After August, BTCPay published a response post saying it would prioritise security patches over new features, and supporters funded a recovery bounty of 10 percent of any returned funds, capped at 3 BTC. Versions 2.4.4, 2.4.5, 2.4.6 and 2.4.7 have all been security releases.

Self‑hosting means the project cannot see inside a merchant's server. It depends on operators reporting in, and it cannot reimburse anyone. Each merchant carries their own loss.

What African BTCPay Operators Should Do Today

One distinction first. BTCPay says funds in wallets whose spending keys were held off the server were unaffected. That includes hardware wallets and, for Lightning, a Blink plugin setup, where the balance sits in your Blink account and a Read and Receive API key cannot send from it. The on‑chain hot wallet is the exposure. The steps below are BTCPay's own, from its incident post and the recovery guidance it links to.

  1. Check your version. Log in and read the bottom of the page. If it shows 2.4.1 or earlier, the rest of this list applies to you, even if you have since updated and even if your balance looks untouched. BTCPay says updating alone cannot remove access an attacker may already have, and an unchanged balance does not rule out an earlier attack
  2. Create a new wallet and sweep any remaining hot‑wallet funds into it. Use a trusted device and a new seed. Reusing the old seed on a new server leaves those funds at risk.
  3. Take the old server offline. Preserve logs and transaction records for the investigation first.
  4. Provision a fresh virtual machine. Install the latest BTCPay Server from trusted sources and connect the new wallet. Do not restore the old server onto the new machine. If a hosting provider runs your server, ask them for help moving to a fresh VM.
  5. Replace every credential the old server could reach. From a trusted device, revoke and replace hosting, SSH, application, API and Lightning credentials. Do not enter new credentials on the old machine.
  6. If you lost funds or saw unauthorized access, email security@btcpayserver.org with your version, when you last updated, when you noticed, your timezone, and the public transaction IDs and addresses. Never send seeds, keys or passwords. Report the theft to local authorities too.
  7. If you were already on 2.4.2 or later on November 1, BTCPay has seen no impact on servers like yours. Update to 2.4.7 anyway: Server Settings, then Maintenance, then Update.

BTCPay's closing advice: if you need a hot wallet for daily operations, keep only what those operations need on the server and move the rest to a wallet whose keys are held off it. And with attackers now using AI to automate their work, install updates as they are released.

Sources