BTCPay Server Orders Emergency Shutdown After Hot Wallets Swept
BTCPay Server issued an emergency shutdown order November 1, 2026 after reports of hot wallets being drained by unauthorized attackers. Founder Nicolas Dorier's preliminary findings point to servers running versions older than 2.4.2. No patch, no confirmed attack vector, no loss figure.
Founder Nicolas Dorier's early findings point to servers running versions older than 2.4.2. No patch, no loss figure, and no confirmed attack vector yet.
Key takeaways
- BTCPay Server told all operators on November 1, 2026 to immediately run
./btcpay-down.shafter reports of hot wallets being swept by unauthorized attackers. - Founder Nicolas Dorier's preliminary assessment links the compromises to instances running versions older than 2.4.2, the patch released in August 2026 after a prior active exploit.
- No fix has been issued, no loss total has been disclosed, and no attack method has been confirmed. The shutdown advisory remains in effect.
BTCPay Server, the open-source Bitcoin payment processor used by merchants worldwide, issued an emergency shutdown call on November 1, 2026 at approximately 22:25 UTC after receiving reports of hot wallets being drained by unauthorized attackers. The project told every operator running an instance to take it offline immediately, with no carve-outs for any version.
The official @BtcpayServer account on X posted: "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." Core contributor Uncle Rockstar Developer (@r0ckstardev) reinforced it: "Not a drill: shut down your BTCPay Server if you have a hot wallet."
What the Preliminary Findings Show
Roughly two hours after the initial alert, founder Nicolas Dorier narrowed the scope. The reports, he said, appear to involve BTCPay Server releases older than version 2.4.2, and that attackers had obtained administrator access on affected servers.
Version 2.4.2 was released in August 2026 specifically to patch an active exploit that had drained Lightning node wallets. At the time, BTCPay stated its on-chain hot wallets were not affected by that incident. The November 1 event involves on-chain hot wallets directly, though whether the two incidents share an attack vector has not been confirmed.
Dorier did not explicitly state that servers running the current release, version 2.4.7, are in the clear. CoinDesk, which first reported the story, noted he stopped short of confirming newer versions are safe. The shutdown advisory was version-agnostic from the start and remains so.
BTCPay's GitHub releases page is the authoritative source for version history and release notes.
The Self-Custody Reality Check
Here is what event-only framing misses: this is a story about what the self-custody model actually demands from operators.
BTCPay's hot wallet works by storing the signing seed on an internet-connected server. That is a documented tradeoff, not a bug. It enables automated payment signing without manual intervention. Merchants who configured BTCPay with a watch-only wallet, where the seed lives on an external signer and never touches the server, are not exposed in this incident.
The two configurations carry entirely different risk profiles, and collapsing them into "BTCPay got hacked" obscures the real lesson.
The harder point: there is no central BTCPay operator who could push an emergency patch to every merchant at once. When a vulnerability surfaces, the project can issue an alert. Every individual operator has to act on it. Any merchant still running a version released before August 2026 was running software that had already been flagged as critically vulnerable after an active exploit.
Version 2.4.2 existed precisely because attackers had already demonstrated they could compromise unpatched servers. The three-month gap between that patch and November 1 is the proximate cause here, not the open-source model itself.
The Ledger reseller incident underscores the same axis of failure: keys and seeds exposed to networked software create attack surface, regardless of how reputable the surrounding stack is. Self-custody closes the counterparty risk. It does not close the operational risk. Those are different problems.
The falsifiable thesis: this incident is a version-control failure, not an indictment of self-hosted payment infrastructure. If the investigation reveals that fully patched servers running 2.4.7 were also compromised, or that the attack vector lives in BTCPay's core architecture rather than in unpatched code, the update-discipline framing is insufficient and the risk is broader.
What to Watch
The investigation is still open. Until BTCPay issues an explicit all-clear or a patch for this November incident, the correct posture is: instance offline, funds moved to cold storage, waiting on official guidance from @BtcpayServer and the project's GitHub. Operators should confirm their version against the releases page and not assume a recent update is sufficient until the project says the vector is closed.
Sources
Frequently Asked Questions
Is a BTCPay Server running version 2.4.7 safe to bring back online?
Possibly, but the shutdown advisory was issued without version restrictions and has not been lifted. Dorier's preliminary findings point to pre-2.4.2 versions as the common thread among compromised instances, but he did not confirm that 2.4.7 servers are in the clear. Keep the instance offline until BTCPay closes the investigation and issues explicit guidance.
What is the difference between a BTCPay hot wallet and a watch-only wallet, and which one is at risk?
A hot wallet stores the Bitcoin signing seed directly on the BTCPay server so it can sign transactions automatically. That seed is the exposure in this incident: attackers who gain administrator access to the server can access the seed and sweep funds. A watch-only wallet stores only the public key on the server and requires an external hardware signer to authorize any transaction. Operators running watch-only configurations are not at risk from this specific attack per current information.
Does running your own BTCPay instance mean you should switch to a custodial processor?
No. A custodial payment processor concentrates counterparty risk in a single company. Self-hosted software distributes that risk across every individual operator, who is then solely responsible for update discipline and key management. The tradeoff is not "safe vs. unsafe" but "your risk vs. their risk."
The answer to this incident is to understand what running your own infrastructure actually requires and to act accordingly.
