BTCPay Server Urges Shutdown After Hot Wallet Drain Reports

Shutdown Order After Unauthorized Drains

BTCPay Server, the open-source software merchants run to accept Bitcoin payments on their own hardware, told operators on 2 November to take their servers offline after reports that funds held in hot wallets had been taken without authorization across multiple servers. The team confirmed the reports in an official X post and asked anyone running an instance to keep it stopped until the investigation is complete, pointing operators to the command “.

The disclosure omits the details operators need most. The team did not publish a loss amount, did not say how many servers are affected, and did not name a cause. It also did not limit the request to any particular version of the software, and no corrected release has been announced, so the instruction covers every deployment in the wild, from a single-store merchant to a large installation. The stop request applies regardless of whether a deployment uses the Lightning integration, since no entry point has been isolated. No transaction identifiers have been published either, which makes independent verification of the losses impossible for now, and the team has not said when its investigation will conclude.

A hot wallet stores private keys on an internet-connected server so that outbound payments, such as refunds, can be processed automatically. That convenience cuts both ways: if the server is compromised, whoever holds access reaches the keys directly. BTCPay’s implementation signs transactions with a seed kept on the server itself, which is exactly the component the reports point at.

October Patch and August Lightning Breach

BTCPay Server is self-hosted by design. Each merchant runs the software on its own server and accepts Bitcoin payments without a payment processor in between, a model that has made the project a fixture of the self-custody wing associated with Bitcoin maximalism. The same architecture explains the response: the developers cannot push a fix to every deployment at once, so shutdowns and later updates happen operator by operator.

The disclosure came four days after the team shipped version 2.4.7, an emergency release published on Thursday 29 October that fixed one critical vulnerability and several moderate ones. The team has not said whether that release has any connection to the current reports, and the new disclosures arrived with the patch already in the field.

The episode also has a precedent. In August, an exploit against versions before 2.4.2 let an attacker steal credentials for LND, the software that operates Lightning payment nodes, and drain funds from Lightning nodes connected to BTCPay. Lightning channels hold their own keys, so stolen credentials let an attacker spend channel balances directly. At the time the team stated that on-chain wallets, including hot wallets created inside BTCPay, were not affected by that flaw; the August drains targeted the Lightning path alone. The wallets named in the current reports sit in exactly that previously cleared category. The Bitcoin network itself is not implicated here either: the losses concern server-side key storage, not proof of work consensus. Because there is no central operator to notify, the shutdown command is the only protection the team can offer while it works. Operators who keep servers running do so at their own risk until a cause is identified and a fix ships.

The shape of the response says as much as the disclosure. In August the team could scope its warning to versions before 2.4.2 and tell everyone else to patch; this time the shutdown order covers all versions, which implies the developers do not yet know where the entry point is. No post-mortem, no attacker transaction identifiers and no remediation timeline have been published, so the losses cannot be verified on-chain for now. Custodial breaches have sometimes been far larger, as when Bitwise CIO Matt Hougan argued that even the $6.3B Binance hack leaves the long-term path unchanged, but self-hosted payment tools concentrate the risk on small merchants who run their own keys. Until the team publishes its findings, what was taken, and from how many servers, remains undisclosed.