- Attackers swept hot wallets on older self-hosted BTCPay Server installations.
- Intruders gained administrator access through a method not yet disclosed.
- No credible drain reports have surfaced for the latest release.
- Unlike Binance users, affected merchants have no fund to cover their losses.
Attackers have been draining hot wallets on self-hosted BTCPay Server installations since October 30, and on November 1 the open-source bitcoin payment processor told every operator to switch their servers off while it searched for the entry point. The project has since traced the drains to version 2.4.1 and older, and blockchain data firm Bitquery estimates that about $1.63 million in bitcoin and litecoin left merchant wallets, a fraction of the $6.3 billion stolen from Binance days earlier, although in BTCPay’s case each merchant carries the loss alone.
Every Drain Hit Version 2.4.1 or Older
BTCPay’s first alert, posted on X late on November 1, told operators to stop their instances with the ./btcpay-down.sh script before anyone knew which releases were exposed. By November 2 the team had linked the attack to installations running version 2.4.1, released on July 23, or anything earlier, and said the intruders had obtained administrator-level access without yet explaining how they got it.
No credible reports of drains have come in for version 2.4.7, the current release, and co-founder Nicolas Dorier said the project’s own public servers running it were not attacked, though the team has not declared any version safe. Hosting provider LunaNode began shutting down older customer instances on its own, so some merchants on hosted plans may find their stores already offline.
Our incident response investigation identified an attack vector targeting instances running versions 2.4.1 (Jul 23, 2026) or older.
We have no credible reports of hot wallet drains for users running the latest 2.4.7 release. We again urge everyone to keep their BTCPay Server… pic.twitter.com/gYxK4Bb7fc
— BTCPay Server (@BtcpayServer) November 2, 2026
87% of the Funds Moved Within Eight Hours
Bitquery’s figures follow addresses that BTCPay’s developer reportedly flagged as linked to the theft, and they remain third-party estimates, since BTCPay has published neither an official loss total nor a count of compromised merchants.
Source: Bitquery, as of 06:00 UTC on November 2.
Bitquery counted 682 sweeps in total, and 87% of the traced value left during a single eight-hour stretch on November 1. The 267 sweeps that came after BTCPay’s public warning, worth roughly $150,000, suggest some operators missed the alert or could not reach their servers in time.
The Seed Phrase Sat on the Server
A BTCPay hot wallet stores its seed phrase, the secret that authorizes spending, on the merchant’s own internet-connected server so the software can sign refunds and payouts without anyone approving each one. BTCPay’s documentation marks that option with a danger warning, because whoever controls the server as an administrator also controls the money. Merchants using a watch-only wallet, where the server holds only a public key for generating payment addresses and the private keys stay on a hardware device, gave the intruders nothing to sign with, and every drain reported so far involved a hot wallet.
Servers That Skipped the August Patch
On August 7 BTCPay confirmed that a critical flaw in versions older than 2.4.2 was being exploited to steal LND administrator macaroons, the credential files that grant full control over a Lightning Network node, and several nodes were emptied while on-chain hot wallets stayed untouched. Dorier has now linked the November compromises to versions predating 2.4.2, the same line drawn in August, which raises the question of how many servers never installed that fix. Dorier later said the team had traces showing that vulnerabilities fixed in 2.4.2 were used, without naming which one, and told operators who have updated at least once since that release that they have no reason to panic.
Version 2.4.7 shipped on October 29, one day before the first traced sweep, and according to its GitHub release notes it fixed 85 issues found through Anthropic’s OSS Scanner program, including one rated critical and 13 rated high. Since the affected servers sit several versions behind it, nothing yet ties the attack to those fixes.
No SAFU Fund Behind a Merchant’s Server
The attack follows Binance’s record loss of about $6.3 billion on October 29, a theft the FBI has attributed to North Korea’s TraderTraitor group. Binance said a compromised engineer’s laptop gave the attacker access to an internal withdrawal service, and on October 31 it reported that 90% of the stolen assets had been replenished from company funds, its Secure Asset Fund for Users (SAFU) and part of its futures insurance fund, with the exchange absorbing the loss instead of customers. Withdrawals reopened in phases on November 1.
BTCPay merchants run their own servers and wallets, so each operator is responsible for securing the installation, and the open-source project can neither switch off compromised servers remotely nor promise reimbursement. Nothing links the two attacks, yet in both the money left through a system already trusted to move it, Binance’s withdrawal service in one case and a merchant’s admin panel in the other.
A Restart Starts With a New Wallet
BTCPay now urges operators to update to 2.4.7 before bringing a server back online, and asks them to preserve their logs and report incidents. Anyone on 2.4.1 or older should not reconnect a hot wallet whose seed sat on a possibly compromised machine, since an intruder with admin access may have copied it. Keeping hot wallet balances small and moving larger sums into watch-only setups was BTCPay’s advice before either incident.
At Bitquery’s cutoff, more than 99% of the traced funds had not moved beyond the addresses that first received them, so the coins had not yet been split up or sent to exchanges, which leaves tracers time to flag them. BTCPay is offering a recovery bounty of 10% of any returned funds, capped at 3 BTC if everything comes back. The project has yet to name the exact flaw or publish a loss figure of its own.
