# BTCPay Server Tells Merchants to Shut Down Servers After Hot Wallets Are Drained

The open-source bitcoin payment processor has given no loss figure and no fix, and its founder says the reports appear to involve versions older than 2.4.2, the release that patched a separate wallet-draining attack in August.

- Published: 2026-11-02T05:45:39.855Z
- Canonical: https://polylog.news/crypto/2026-11-02/btcpay-server-tells-merchants-to-shut-down-servers-after-hot
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [CoinDesk](https://www.coindesk.com/tech/2026/11/02/btcpay-a-bitcoin-payment-tool-tells-users-to-switch-off-their-servers-after-reports-of-drained-wallets), [Polylog editors](https://polylog.news), [CoinDesk (August 2026)](https://www.coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes), [TFTC](https://www.tftc.io/btcpay-server-hot-wallet-drained-emergency-shutdown)

BTCPay Server, the self-hosted payment software that many bitcoin merchants run on their own machines, has [urged users to shut down their instances](https://t.me/cointelegraph/72991) after reports that attackers emptied hot wallets stored on those servers. [CoinDesk reports](https://www.coindesk.com/tech/2026/11/02/btcpay-a-bitcoin-payment-tool-tells-users-to-switch-off-their-servers-after-reports-of-drained-wallets) that the project says it is still investigating and has not given a loss figure or announced a fix. Nicolas Dorier, BTCPay's founder, said the reports appear to involve releases older than version 2.4.2.

The attack method has not been confirmed. What is known is how the wallets are built. When a merchant creates a hot on-chain wallet inside BTCPay, the seed phrase that controls the coins is stored on the server itself, and that server is connected to the internet. Anyone who gains control of the server or of its stored secrets can sign transactions. [TFTC's summary](https://www.tftc.io/btcpay-server-hot-wallet-drained-emergency-shutdown) of the project's guidance tells affected users to move their funds to a wallet whose keys BTCPay has never held. The keys of an existing hot wallet cannot be rotated, so a leaked seed stays usable for as long as funds remain at that address.

This is the second BTCPay incident in three months. In August, version 2.4.2 shipped to patch [an active exploit that drained merchants' Lightning node wallets](https://www.coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes). The project has not said whether the November reports share an attack path with the August flaw. If they do, the losses would fall on operators who never installed the August patch rather than on a new vulnerability. Merchant setups that use watch-only wallets, where BTCPay holds only public keys and the signing keys stay in hardware or offline wallets, are not exposed to this kind of theft.

## What this means

The exposure affects small merchants who run their own servers. Many of them treat BTCPay as an appliance and do not update it, and the software stores spending keys on an internet-connected server. Self-hosted payment infrastructure is the commercial core of the "use bitcoin as money" argument. Every incident like this raises the effective cost of self-custody for businesses and pushes them toward custodial processors, which re-creates the counterparty risk bitcoin was designed to remove. Two outcomes are plausible, and the deciding fact is whether a new vulnerability exists. If the drains trace only to unpatched servers older than 2.4.2, the likelier result is a contained loss and a push for automatic updates and watch-only defaults within weeks. If they trace to a flaw in current releases, expect a larger disclosure and merchants leaving for custodial alternatives over the following months. Publication of a root cause affecting 2.4.2 or later would prove the contained reading wrong.

## What to watch

- The project's post-mortem, and whether it names an affected version range that includes 2.4.2 or later. That would turn an update-discipline problem into a software defect.
- Whether hosted BTCPay providers report affected customers or switch hot wallets off by default. Default changes would show how seriously operators read the risk.
- Any loss estimate from on-chain researchers who cluster the drained addresses. The size would decide whether this stays a merchant-level incident or becomes an ecosystem-level one.