BTCPay Server tells users to shut down after hot wallet drains

BTCPay Server, a free tool that lets merchants take bitcoin payments, told users on November 1 to switch off their servers. The project said attackers had swept funds from hot wallets. It has not said how much was taken.

The alert went out on the project's verified X account. "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers," it read. Operators were told to run a shutdown command, ./btcpay-down.sh, and keep their instances off until the investigation ends. CoinDesk and crypto.news both reported the warning within hours.

How a payment tool ends up holding coins

BTCPay Server is self-hosted. A merchant runs it on their own machine, or with a hosting provider, and takes bitcoin straight from the buyer with no payment company in between. That is the appeal. It is also the risk. The software is open source and free to run, which is why many privacy-minded sellers and small merchants favor it over a hosted processor that keeps custody and charges a fee. Some operators also keep a hot wallet on the same server, connected to the internet so payments settle at once, and that wallet is what the attackers reached. Money held offline, in cold storage, was not the target. The trade every self-hoster makes is control in exchange for being their own security team.

What operators were told to do

Running the shutdown script stops the software and leaves the wallet unreachable while the project digs in. The command is the project's standard way to bring a Docker-based install down, so most operators already had it to hand. "Swept," the word BTCPay used, means coins moved out of a wallet in a single transfer, the mark of an automated drain rather than a slow leak. Some users never had to act. BTCPay said people who run the software through a hosting provider might find their instances already stopped, shut down automatically as a precaution. The project publicly thanked one provider, LunaNode, for moving fast. For a merchant mid-sale, the effect is a till that suddenly stopped taking bitcoin, with no clear word yet on when it is safe to switch back on.

Which versions are affected

About two hours after the first post, co-founder Nicolas Dorier said the thefts appeared to involve releases older than version 2.4.2. He said an attacker had logged in with administrator rights on the affected servers. How they got those rights, he did not say. The project's own public servers, running the latest 2.4.7 release, were not touched.

A day later the project narrowed it again. "We have no credible reports of hot wallet drains for users running the latest 2.4.7 release," the account posted on November 2.

Version dates fill in the rest. BTCPay's GitHub page shows 2.4.1 shipped on July 23, 2026, and 2.4.2 arrived on August 7. Those August notes flagged a critical flaw that was "being actively exploited" at the time and pushed users to update quickly. The newest release, 2.4.7, landed on October 29 and closed 85 separate security findings from a code scan: one critical, 13 high, 52 medium and 19 low. Those fixes came through a scan run under Anthropic's open-source scanner program, the release notes say, and the project called updating highly recommended for servers shared by several merchants. Anyone drained on an older build had been running months-old code.

A second theft in three months

This is not the first theft tied to old BTCPay builds this year. In August 2026 the project confirmed a separate incident that abused a flaw in versions before 2.4.2, one that exposed the credential files for a connected Lightning node. The 2.4.2 release fixed it. That same August update also urged operators to upgrade a companion tool, NBXplorer, to version 2.6.10, and closed a two-factor login bypass. The pattern that links both episodes is simple. Servers kept current were spared. Servers left on last summer's code were not.

What is not known

No loss figure. BTCPay has not said how much bitcoin was taken, how many servers were hit, or how many operators reported a drain. It has not confirmed the exact weakness the attackers used, nor how they first gained administrator access. No recovery of any stolen funds has been announced.

One hard limit is worth stating plainly. Updating does not undo a compromise that already happened. An operator whose wallet was emptied on an old version will not get those coins back by installing 2.4.7. The new release protects what is left, not what is gone.

What to watch

Scale is the first open question. Until BTCPay publishes a loss total and a count of affected servers, the size of this is guesswork, and early numbers in cases like this tend to move as more operators check their wallets. The second question is the entry point. A confirmed account of how an attacker reached administrator rights would show operators whether the fault sat in the software, in weak server setups, or in both.

The timing is grim for the wider market. Chainalysis tied 89 percent of 2026's crypto hack losses to a single source, and Binance only reopened bitcoin withdrawals this week after a $6.3 billion breach. Bitcoin traded near $78,010 at 07:41 UTC on November 2, according to CoinGecko, soft on the week. For the merchants who run their own node, the episode repeats a point older than any single bug. A hot wallet holds exactly what can vanish in one transfer.