BTCPay Server, the open-source software that lets merchants accept Bitcoin without handing a cut to a third-party processor, told every operator running an instance to switch it off on the evening of November 1, 2026, after it began receiving reports that hot wallets were being drained by unauthorized attackers.
We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you are running an instance, please shut it down (./btcpay-down.sh) until we complete our investigation.
— BTCPay Server (@BtcpayServer) November 1, 2026
The alert, posted to the project’s official X account at 5:25 p.m. ET on November 1, 2026, marks the first time the project has told its entire self-hosted user base to take servers offline since an August incident involving leaked Lightning credentials. This time the reports point at a different target: the on-chain hot wallets that live inside BTCPay Server itself, not the Lightning channels wrapped around it.
Bitcoin traded near $78,375 on November 2, up about 0.8 percent over the prior 24 hours, as the wider market continued to rebuild after the October 29 Binance theft. The BTCPay warning is a separate, narrower story about the self-hosted edge of the Bitcoin payments stack rather than a market-moving event, but it lands in the same security-heavy week.
A Self-Hosted Payment Stack Told to Pull the Plug
BTCPay Server is not a custodian. Merchants download the software and run it on their own hardware or cloud instance, which means the exchange-facing risk is replaced by a different one: the operator’s own server now holds the private keys. The project’s wallet documentation describes its hot-wallet feature as using a seed stored on the server to sign transactions, so funds can move without an external signing device.
That architecture is the whole point of the shutdown instruction. A hot wallet that can sign on the server is also a hot wallet an attacker who reaches the server can sign with. The project’s own advice to run ./btcpay-down.sh and leave the instance offline until the investigation concludes is an acknowledgment that, right now, the project cannot yet say which versions or configurations are safe.
The warning was not limited to a particular release. That is the detail that separates this from a routine patch advisory: BTCPay did not tell operators “update to version X” or “disable feature Y.” It told them to stop the software entirely, which is the strongest guidance the project has issued since it began publishing security advisories.
No Loss Figure, No Version Limit, No Patch
Conspicuously absent from the November 1 notice is any confirmed loss figure. The project said it was “receiving reports” that hot wallets were “being swept,” but it did not state how many instances were affected, how much Bitcoin was taken, which versions or configurations were involved, or when a patch might arrive.
That gap matters because BTCPay is self-hosted: the project cannot see into a merchant’s server to count the damage the way a centralized exchange can audit its own database. Any loss tally will have to be reconstructed from on-chain movement plus operator reports, and the project has not yet published one.
Founder Nicolas Dorier told outlets that early findings pointed at affected servers running versions older than 2.4.2, with attackers logged in as administrators, but he cautioned that investigators had not established how that access was obtained. His remarks are preliminary and attributed to him, not yet a published technical finding from the project.
Three Days After an Emergency Release
The warning follows BTCPay Server 2.4.7, an emergency release dated October 29, 2026. The release notes describe the update as fixing 85 security findings reported through Anthropic’s OSS Scanner program: 1 critical, 13 high, 52 medium, and 19 low severity.
“This bug-fix release addresses security, reliability, and payment-accounting issues,” the notes read, adding that the project thanked “Anthropic and its OSS Scanner program for reporting these findings and providing reproducers and proposed fixes.”
The timing is uncomfortable but does not by itself prove a link. Two days and change separate the 2.4.7 release from the hot-wallet reports, and the project has explicitly said there is no confirmed connection between the vulnerabilities fixed in that release and the current drains. Dorier’s observation that the project’s own public servers running 2.4.7 had not been attacked is useful but is not proof that every updated installation is safe, a distinction the project has not tried to blur.
The August Precedent Was a Different Wound
BTCPay Server has been here before, but not in this exact place. In August 2026, the project confirmed a flaw that let attackers obtain LND admin macaroon credentials from affected instances and use them to drain connected Lightning nodes. That incident prompted version 2.4.2 and a similar demand that operators update or shut down, and it is the reason the current shutdown instruction reads so familiar.
The August flaw, however, explicitly did not affect the standard on-chain wallets inside BTCPay, including its hot wallets. This is why the new reports are notable: they point at precisely the wallet type that was outside the scope of the August bug. A Lightning-channel drain and an on-chain hot-wallet sweep are different surfaces, and the project treating the new reports with a blanket shutdown suggests it sees a genuinely separate vector rather than a replay of the earlier incident.
The wider self-hosted Bitcoin stack has spent the second half of 2026 wrestling with the same class of problem. In late August, Core Lightning told its node operators to upgrade or go offline over a cluster of AI-reported bugs, a structurally similar call from a different implementation.
Shut Down, Stay Offline, Wait for a Root Cause
For the merchant or hobbyist running an instance, the concrete steps are short. Run the project’s shutdown command, leave the server offline, and wait for an official statement that names affected versions, a root cause, and a remediation path. Updating alone should not be treated as clearing an active compromise, because the entry point has not been established.
Operators should also distinguish the project’s confirmed instructions from community reports as the investigation develops. Nothing in the alert establishes a total, a root cause, or a safe restart point, and the project has been careful not to claim one.
The incident is a reminder that self-custody infrastructure concentrates risk at the server even when it removes the exchange. Earlier this year, Bitget confirmed a $351.6 million hot-wallet breach, an exchange-side episode that illustrates how hot-wallet key management remains the highest-value target across the industry regardless of who is holding the keys.
The self-hosted edge has had a bruising second half of 2026. A Coldcard hardware-wallet exploit drained roughly $114 million from users in August, and Galaxy researchers tied a separate wave of losses to weak seed generation that moved about $70 million from Bitcoin cold wallets. The BTCPay episode fits the same pattern: the attack surface is no longer just the exchange, it is the key-holding software that operators run themselves.
Every Number That Matters Is Still Missing
The next concrete signal will be a follow-up from BTCPay Server: a technical post-mortem, a version that closes the vector, or a loss tally once the project can count what moved. Until then, the standing instruction is to keep affected instances offline, and the open questions are the entry point, the affected version range, and the total taken.
The alert is a developing story rather than a resolved one. Its central fact is settled — the project told operators to shut down in the face of hot-wallet sweeps — but every number that matters, from the loss to the vulnerable versions, is still behind the project’s own “receiving reports” language.
