BTCPay Server Tells Every Merchant to Shut Down: Bitcoin Hot Wallets Drained — 5 Checks Before You Restart

BTCPay Server's Shutdown Order, Explained in 30 Seconds

On the evening of November 1, 2026, BTCPay Server told every operator running its open-source Bitcoin payment software to switch it off. The reason was blunt: attackers were sweeping Bitcoin from merchants' internet-connected hot wallets. The project's message on X read: "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you're running an instance, please shut it down (./btcpay-down.sh) until we complete the investigation." A sweep means the coins were moved out in one go — not dripped out over days, but taken wholesale. No loss total has been disclosed, no count of affected servers has been published, and investigators have not yet said how the attackers got in. What is known is narrowing fast: the reports point at installations running version 2.4.1 or older, while the latest release, 2.4.7, has no credible reports of wallet drains so far. If you run a BTCPay instance, the safe move is the one the project itself ordered: shut it down, check your version, and do not restart on hope.

This is the second time in three months that BTCPay Server has faced a live attack on its self-hosted stack — and the first time it has told its entire user base to pull the plug over on-chain hot wallets. Here is what happened, what the version numbers actually mean, and the five checks to run before you ever bring a server back online.

What BTCPay Server Is — and Why a Shutdown Order Matters

BTCPay Server is free, open-source software that lets a business accept Bitcoin payments without handing a cut to a third-party processor and without giving up custody to an exchange. A merchant downloads it, runs it on their own hardware or cloud server, and connects it to their own wallets. That design is the whole point: no middleman can freeze the money, take a percentage, or get hacked on the merchant's behalf.

But self-hosting swaps one risk for another. When the merchant is their own payment processor, the merchant's own server holds the keys. A hot wallet — a wallet that lives on an internet-connected machine so it can sign transactions automatically — is convenient for a shop that needs to receive payments around the clock. It is also a wallet that an attacker who reaches the server can sign with. That is the trade-off at the heart of this incident, and it is why the project's instruction was so stark: the only guaranteed protection while the entry point is unknown is to take the machine offline.

It is worth being precise about what this story is not. This is not an exchange hack. It is not the Binance hack that drained $6.3 billion the previous week, and it is not a flaw in Bitcoin itself. Bitcoin traded near $78,375 on November 2, up about 0.8 percent over 24 hours, as the wider market kept rebuilding after the Binance theft. The BTCPay warning is a narrower, separate story about the self-hosted edge of the Bitcoin payments stack — but for the merchants running it, it is the one that decides whether their takings are still there in the morning.

Timeline: How the Warning Unfolded

The sequence matters, because the project's guidance tightened as the investigation narrowed — and early reports that seemed to say "everyone is at risk" later resolved into a version-specific picture.

Date	What happened
July 23, 2026	BTCPay Server 2.4.1 released — later identified as the newest version in the suspected affected range.
August 2026	Attackers exploited a flaw in versions before 2.4.2 to obtain LND admin credentials and drain connected Lightning nodes. On-chain hot wallets were explicitly not affected by that flaw.
October 29, 2026	Version 2.4.7 released, addressing 85 security findings from Anthropic's open-source scanner program: 1 critical, 13 high, 52 medium, 19 low.
November 1, 2026, ~22:25 UTC	BTCPay Server posts the emergency warning: hot wallets are being swept; all operators told to run ./btcpay-down.sh and stay offline.
November 1, late evening	Founder Nicolas Dorier says reports "appear to involve" releases older than 2.4.2, and that the project's own public servers on 2.4.7 were not attacked. Attackers logged in as administrators on hit servers.
November 2, 2026	Investigation narrows the suspected vector to 2.4.1 or older. Hosting providers including LunaNode shut some instances down precautionarily; businesses including Coincards took installations offline. No loss total, no patch, no all-clear yet.

The timeline carries an important caution. The initial warning deliberately did not limit itself to one version, because at that point the project could not say which configurations were safe. The later narrowing to 2.4.1 and older is a preliminary finding, not a verdict. Founder Nicolas Dorier has said the project's public servers on 2.4.7 were not attacked — but he has not said newer versions are safe, and the shutdown instruction has not been lifted. Treating "we run 2.4.7" as an all-clear would be exactly the mistake the project is warning against.

What the Attackers Actually Did — and What Is Still Unknown

Three facts are established. First, attackers gained administrator access on the affected servers. Second, they used that access to sweep hot wallets — moving available funds out in a single transfer. Third, the reports cluster on installations running versions older than 2.4.2, with the investigation later pointing specifically at 2.4.1 or earlier.

Everything else is open. Investigators have not determined how the attackers obtained administrator access — whether through stolen login credentials, a software flaw, or another route. No total amount stolen has been disclosed, and no number of compromised servers has been published. There is no confirmed link between the wallet drains and the 85 findings fixed in version 2.4.7, even though that release landed just three days before the warning. And there is no incident-specific patch yet, because there is no confirmed root cause to patch.

That uncertainty is itself the story. In August, the flaw was understood: leaked Lightning credentials, Lightning nodes drained, on-chain wallets untouched. This time the target is different — the on-chain hot wallets themselves — and the entry point is not yet understood. Until BTCPay publishes a technical post-mortem, a version that closes the vector, or a loss tally, the honest description of the situation is "developing, with the shutdown instruction still standing."

For context on why hot wallets are the soft target, see our guide to how crypto wallets work: a wallet that can sign on a server is a wallet an attacker who reaches that server can sign with. The security question is never whether the cryptography works — it does — but who else can reach the machine that holds the keys.

5 Checks Before You Restart a BTCPay Server

If you operate a BTCPay instance, run these checks in order. Do not skip to the restart.

1. Confirm the instance is actually down. Run ./btcpay-down.sh and verify the services stopped. If you run through a hosting provider, check whether your instance was already shut down automatically — several providers took precautionary action on November 2. A server you believe is off but is still serving is still exposed.

2. Identify your exact version — and treat 2.4.1 or older as affected. The suspected range is 2.4.1 (released July 23, 2026) and earlier. If you are on 2.4.2 or later, you are outside the suspected range, but that is not an all-clear while the investigation is open. If you cannot determine your version, treat the instance as affected.

3. Audit administrator access before anything else. Attackers logged in as administrators on hit servers. Review every admin account, remove any you do not recognize, rotate all admin credentials, and check for unfamiliar users, API keys, or scheduled jobs. If you find an account you cannot explain, assume compromise and preserve the logs rather than wiping them — the project has asked affected users to submit incident details and server logs.

4. Move funds to cold storage and verify balances independently. Check hot-wallet balances against your own records, not just the server dashboard. Any shortfall should be treated as a sweep until proven otherwise. Going forward, keep only the minimum operating float in a hot wallet; the bulk belongs in cold storage. Our guide to storing crypto safely covers the cold-storage setup that would have limited this incident to a float, not a treasury.

5. Wait for a real all-clear, then upgrade — not the other way round. Do not restart on the strength of "we run 2.4.7" alone. The signal to watch for is one of three things from BTCPay itself: a technical post-mortem naming the entry point, a release that closes the vector, or an explicit statement that instances may restart. When that lands, upgrade to the newest release, re-verify admin access, and only then bring the hot wallet back online with a small float.

What Most People Get Wrong About This Incident

"Bitcoin was hacked." No. No flaw in Bitcoin's protocol has been alleged. The targets were wallets on individual merchant servers running one piece of payment software. Bitcoin's network kept running throughout, and the price barely moved on the news — a sign the market read this correctly as a software-operations incident, not a protocol event.

"Self-hosting means you can't be hacked." Self-hosting removes the exchange as a target. It does not remove you as a target. The August incident and this one both hit the operator's own infrastructure. The security model of self-hosting is "you are responsible" — which is a feature for sovereignty and a liability for anyone who does not patch.

"Only old versions are at risk, so I'm fine." The version finding is preliminary. The project's own public servers on 2.4.7 were not attacked, but the project has not declared newer versions safe, and the shutdown warning has not been withdrawn. Version numbers are evidence, not guarantees.

"This is just a repeat of August." The August flaw drained Lightning nodes via leaked admin credentials and explicitly did not touch on-chain hot wallets. This incident drains on-chain hot wallets. Similar shape, different target — and possibly a different entry point, which is why the investigation is not simply re-applying the August fix.

"Small merchants don't need to worry." The victims are merchants — the exact businesses BTCPay exists to serve. A gift-card company and hosting customers have already taken systems offline. If you accept Bitcoin through BTCPay, this warning was addressed to you personally.

Why This Week Keeps Testing Crypto's Security Story

The BTCPay warning lands in the worst possible week for confidence in crypto custody. Days earlier, Binance — the world's largest exchange — disclosed a $6.3 billion theft, then reported it had covered about 95% of the affected assets and restarted withdrawals in phases from November 1. The market's reaction to that event was notably calmer than the FTX collapse, when Bitcoin fell 19% in three days. This week, Bitcoin dipped to about $77,600 late on Sunday and recovered above $78,500 within hours.

But the two incidents teach opposite lessons, and both matter. Binance shows that a giant custodian can absorb a historic theft and keep operating — at the cost of proving, once again, that users' funds depended on one company's balance sheet. BTCPay shows the mirror image: nobody's balance sheet stands behind a self-hosted server, so the merchant's own patching discipline is the entire security budget. Neither model is free. The question for anyone holding crypto is not "custody or self-custody" in the abstract — it is which failure mode you have actually prepared for. Our post-hack checklist for buyers, 10 checks before you send a dollar, applies the same discipline to exchange users.

The broader pattern is worth naming. In a single week, the industry has seen the largest exchange theft on record and an emergency shutdown order for its best-known self-hosted payment tool. Both were contained — Binance by its own funds, BTCPay by telling everyone to stop. Containment is good news. But containment that depends on a shutdown order is a reminder that "be your own bank" comes with a job description: patch, audit, rotate credentials, and keep the float small. The merchants who did that job will restart with a scare. The ones who did not are the incident report.

What Happens Next

Watch for three signals, in this order. First, a BTCPay statement narrowing or confirming the entry point — stolen credentials versus software flaw changes everything about who else is at risk. Second, a release or patch tied to that finding, rather than a general upgrade. Third, an explicit all-clear or restart guidance. Until at least the first of those lands, the standing instruction is unchanged: keep affected instances offline.

Merchants who need to keep taking payments in the meantime face an uncomfortable choice: pause Bitcoin acceptance, or route payments through a third-party processor and accept the fees and custody trade-off they chose BTCPay to avoid. There is no clean third option while the investigation is open, and pretending otherwise is how floats get swept.

For everyone else — holders, traders, and the merely curious — the takeaway is simpler. The week of the $6.3 billion Binance theft and the BTCPay shutdown order is the week to audit your own setup: where your coins live, who can sign for them, and whether your software is on the version you think it is. The next incident will not announce itself with a shutdown order. It will just move the money.

Frequently Asked Questions

Is BTCPay Server safe to use right now?

Not unconditionally. The project has told operators to shut instances down while it investigates hot-wallet sweeps, and that instruction has not been lifted. Installations on version 2.4.1 or older are in the suspected affected range; newer versions have no credible drain reports so far, but have not been declared safe.

Which BTCPay versions are affected?

Reports point at releases older than 2.4.2, with the investigation narrowing to version 2.4.1 (released July 23, 2026) or earlier. Version 2.4.7, released October 29, 2026, is the latest release and the project's own public servers on it were not attacked.

How do I shut down my BTCPay Server?

Run ./btcpay-down.sh on the server and verify the services stopped. If you use a hosting provider, check whether your instance was already shut down automatically. Leave it offline until BTCPay publishes further guidance.

Has BTCPay said how much Bitcoin was stolen?

No. As of November 2, the project has disclosed no loss total and no count of affected servers. Anyone quoting a figure is speculating.

Is this connected to the Binance hack?

No evidence connects the two. The Binance theft hit a centralized exchange; the BTCPay reports hit self-hosted merchant servers. They happened in the same week, but they are separate incidents with separate causes.

What should I do if my BTCPay hot wallet was drained?

Keep the instance offline, preserve server logs, audit admin accounts, and submit incident details and logs to the project as requested. Do not wipe the server before preserving evidence, and do not restart with fresh funds until the entry point is understood.

Conclusion

BTCPay Server's shutdown order is the rarest kind of warning in crypto: a project telling its entire user base to stop, before it fully understands why. That honesty deserves credit — and it deserves to be taken literally. Shut the instance down, check the version, audit admin access, move the bulk to cold storage, and wait for a real all-clear. The merchants who treat this as a drill will be fine. The ones who treat it as noise are the reason the warning had to be written. In a week that already proved even the biggest exchange can be robbed, the cheapest security upgrade available is the one BTCPay just ordered for free: turn it off until you know.

Sources: CoinDesk, Bitcoin.com News, crypto.news, Blockchain Reporter, Cyber Security News.