BTCPay Server tells self-hosters to shut down after on-chain hot wallets drained

The BTCPay Server team told operators of self-hosted instances to shut them down on November 1, 2026 after merchants reported that on-chain hot wallets were being swept by unauthorised attackers. The project's primary alert came from the official BTCPay Server X account, followed about two hours later by founder Nicolas Dorier's follow-up post, which narrows the reported thefts to releases older than 2.4.2 and says the attacker is logging in as administrator on affected servers. Coverage: CoinDesk, Bitcoin.fr.

What happened

The BTCPay X account posted on Sunday night UTC: "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you are running a BTCPay instance, please shut it down (./btcpay-down.sh) until we complete the investigation." The project pointed operators at the standard shutdown script shipped with the Docker deployment.

About two hours later Dorier added that the reports "appear to involve BTCPay Server releases older than version 2.4.2," and that the project's own public servers — currently on 2.4.7, the emergency release pushed on October 29, 2026 — "were not attacked." The team gave no loss figure, no count of affected servers, and no CVE for the November 1 incident. The disclosed detail about the primitive is that the attacker gains administrator-level access on the compromised instance; how that access is obtained is still under investigation.

Mechanism — why admin access on an older build drains the hot wallet

BTCPay's hot-wallet feature lets a merchant run a wallet whose spending key is held on the server itself, so the daemon can sign outgoing payments without an operator in the loop. The documentation flags that model's trade-off explicitly: a hot wallet "can automatically sign payments with a seed phrase stored on the server," so anyone who gains full access to the server can move the coins. Reference: BTCPay's own wallet documentation.

Two threads tie the November 1 alert to the project's August 2026 incident, but they are distinct:

• The August flaw was fixed in 2.4.2 and affected LND Lightning credentials stored on the server, letting an attacker steal macaroons and drain Lightning nodes rather than on-chain BTCPay-generated wallets. CoinDesk's August 8 piece covered that primitive and the recommended mitigations (refresh macaroons, move funds out of exposed wallets).
• The November 1 reports are on-chain hot wallets, with the attacker already holding an admin session. That is a different exploitation path, consistent with operators who never upgraded past 2.4.2 running stale credentials, misconfigured reverse proxies or exposed admin endpoints — the project has not confirmed which, hence the shut-everything-down advice while triage continues.

Operators on 2.4.7 should still read the official follow-up when it lands; Dorier wrote only that the public instances in that version were not hit, not that 2.4.7 is proved immune.

What to do right now

1. Shut the instance down with ./btcpay-down.sh if the server is still running an on-chain hot wallet and the version is not confirmed current. The team's instruction is explicit.
2. Rotate admin credentials and SSH keys on the host; assume the admin session that drained the hot wallet is persistent until proved otherwise.
3. Move funds out of hot wallets on affected instances. The hot-wallet seed on disk is already compromised if the server was.
4. Audit login history — the project's status pages, the server's nginx and btcpay logs, and any 2FA provider will show the admin logins to attribute.
5. Wait for the full write-up before bringing the instance back. Watch the official BTCPay Server X account and the project's GitHub for the post-mortem.

Context — the pattern on self-hosted Bitcoin tooling

The November 1 alert is the second active-exploitation incident on BTCPay in roughly three months. Our prior coverage of the August LND drain and the recovery bounty is on this site; the pattern across both is that self-hosted merchant stacks are now a priority target, and that operators who do not maintain a current build inherit the risk of every unpatched flaw stacked behind them. Hardware-wallet-only configurations — where the signing key is not on the server — are not exposed to the drain primitive here, by construction. The project's own documentation already flags that trade-off; the November 1 incident is the one that forces the choice.

What other outlets missed

Several early write-ups framed the November 1 alert as a "sequel" to the August LND exploit on BTCPay's macaroon handling. The two incidents share a project and a victim profile but are different primitives: August was credential theft inside the Lightning stack, November 1 is administrator session abuse against the on-chain hot-wallet feature. Dorier's own follow-up draws the line (versions older than 2.4.2 reported, servers on 2.4.7 not hit); conflating them hides which operators are actually exposed today.