BTCPay Server, the self-hosted software that lets merchants accept Bitcoin without a processor in between, told operators to switch their instances off on the evening of November 1, 2026, after reports that hot wallets were being drained. The project’s own incident post is more precise than the shutdown alert: Bitcoin and Litecoin were stolen from servers running version 2.4.1 or earlier, and the attackers used a method different from the one patched in 2.4.2 back in August.
Two incidents sit close together, and the difference is the point. The August advisory fixed a vulnerability that exposed LND credential files, the .macaroon files that control a Lightning node, and the team said that issue affected Lightning deployments while leaving on-chain wallets untouched. The November thefts are the reverse: they hit on-chain hot wallets, where the private keys needed to spend funds sit on the server itself. A wallet whose spending key stays off the server, such as a hardware wallet, was not affected in either case.
The phrase “hot wallet” is doing real work. A self-hosted machine that receives bitcoin and holds the key to spend it on that same machine is a hot wallet, and it is exposed the moment the machine is compromised. BTCPay’s guidance is blunt about the consequence: an update alone cannot remove access an attacker may already have, and an unchanged balance does not rule out an earlier theft. Anyone on 2.4.1 or earlier is told to move to a fresh server, a new wallet, a new seed, and sweep whatever funds remain.
That instruction is heavy, and the project admits it. “We wish we had done more to reach users still running older versions,” the incident post says. The August patch shipped on August 7; the November attacks appear to have found a way around it on servers that never moved past July’s 2.4.1. Self-hosted software does not update itself. Whoever installed BTCPay is the one checking the version in the footer and pulling the latest release, because there is no vendor on the other end doing it for them.
For operators, the checklist is short. Log in and check the version at the bottom of the page. If the server was already on 2.4.2 or later when the November 1 warning went out, the team saw no impact on those machines. If it was on 2.4.1 or earlier, treat the machine as compromised even if nothing is missing, sweep remaining funds into a new wallet on a fresh install, and do not reuse the old seed. If funds were stolen, treat the whole machine and its secrets as burned and preserve the logs before wiping it.
The durable lesson is not about BTCPay’s specific bug. It is about what “self-hosted” and “non-custodial” remove and what they do not. Running your own node removes the exchange counterparty but moves every operational duty onto the operator: patching, monitoring, backups, and the choice of where the spending key lives. A merchant who keeps that key on the server is running a hot wallet, and a hot wallet is a trade-off, not a software defect. The safer default the project keeps recommending is to hold the spending key off the server and let the instance only receive.
Source: BlockchainReporter.