BTCPay Server Attacker Has Collected 18.46 BTC as Project Ties Hot Wallet Drains to Outdated Versions
An attacker who broke into outdated BTCPay Server instances and emptied their hot wallets has gathered 18.46 BTC, worth about $1.44 million, at a single address, according to our analysis of on-chain data [15]. The open-source payment processor told every operator to shut down late on November 1 and later said the attack targeted servers running version 2.4.1 or older [1][2].
Nicolas Dorier, BTCPay Server's founder, published the address after the project narrowed the scope of the breach [14]. Of the 18.43 BTC the attacker has since moved out of it, 17.9 BTC was sitting untouched in 16 single-use addresses when we checked on November 2 [15]. Neither BTCPay nor any outlet we reviewed has put a figure on the losses or the number of merchants hit [10][11].
"Please shut it down"
Because each merchant hosts the software on their own machine, there was no central switch to flip [7]. Some hosting providers acted on their own. BTCPay later thanked LunaNode and others for automatically shutting down customer instances so older versions could not be exploited [3].
In the early hours of November 2, the picture narrowed. "Our incident response investigation identified an attack vector targeting instances running versions 2.4.1 (Jul 23, 2026) or older," the team wrote, adding that it had "no credible reports of hot wallet drains" on the current 2.4.7 release [2].
Admin access
Dorier said the project's own public servers, which run 2.4.7, were not attacked. "The attacker managed to log in as admin on those instance, we are still trying to figure out how," he wrote [4]. He later said the team had found traces of pre-2.4.2 vulnerabilities being used and that a detailed blog post would follow [5][6]. Replying to one user, he said the drains did not appear to involve a new vulnerability [17].
On a server configured with a hot wallet, admin access is enough. The seed is stored on the internet-connected machine so BTCPay can sign payments automatically, a feature its documentation flags with a "DANGER" label [7].
The incident follows a separate breach in August, when version 2.4.2 patched a critical, actively exploited flaw that let unauthenticated attackers steal LND credentials and drain Lightning nodes [8]. BTCPay said at the time that on-chain wallets, hot wallets included, were not affected [8]. Those are the wallets now being swept, on servers that never took that update. Version 2.4.7, released October 29, fixed 85 security findings, one rated critical, according to its release notes [9].
Guidance for merchants
Dorier sought to reassure operators who have kept up with releases. "At least for those who already updated at least once since the release of 2.4.2, there is no reason to panic," he wrote, urging users to update often and adding, "don't keep too much in your Hot Wallet" [6]. After the team sorted through the reports, he said, no one running a version above 2.4.2 had been affected [6]. He runs 2.4.7 with a hot wallet himself [18].
For those who weren't on a patched version, his advice was blunt. Asked whether replacing the seed was enough, Dorier replied, "Not only the seed, they should consider the server cooked" [13]. In practice, that means moving any remaining funds to a new wallet whose seed has never been on that machine.
The project's standing instructions are to check the version shown in the admin footer and update through the server's maintenance settings or with btcpay-update.sh, keeping the server offline until that is possible [1][8][12]. Affected operators are asked to send details and logs to security@btcpayserver.org [2]. After the August incident, BTCPay also urged victims to report thefts to police and to contact any exchange where stolen funds surface [12].
The longer-term message is about how much to leave online. "Don't put more than you are ready to lose in hot wallet. We can't guarantee it won't happen again," Dorier wrote [17]. The project's blog recommends cold storage wherever possible and sweeping excess funds there regularly [12]. A receive-only setup, with the seed kept off the server, still accepts payments and leaves an intruder nothing to sign with [7]. The machine underneath needs the same discipline, as our guide to Linux kernel flaw CVE-2026-98432 explains.
What the blockchain shows
We pulled the full history of the address Dorier posted, bc1p0f7w…63r7, from mempool.space and followed each outgoing payment, the method we used on Binance's hacked hot wallet [14][15].
The attacker's address received 18.46 BTC, about $1.44 million, in 567 transactions, and 17.9 BTC of what it sent out had not moved when we checked on November 2 [15].
All 567 incoming transactions were confirmed at the time of our read, and at mempool.space's price of $77,984 they add up to roughly $1.44 million [15]. They spent coins from 10,471 distinct addresses, and 499 had a single output paying the attacker, the signature of a wallet being emptied in one go [15]. The data can't say how many stores that represents, since one wallet can be swept more than once.
Most sweeps were small. 459 deposits were below 0.01 BTC, and only five exceeded 1 BTC, totaling 7.74 BTC, the largest being 1.86 BTC [15].
The timeline stands out. The first deposit arrived on October 30, more than a day before any public warning, and by the end of October 31 the address had received 0.61 BTC in 20 transactions [15]. The bulk followed on the afternoon of November 1, including 8.8 BTC in a single hour [15]. By the time BTCPay told operators to shut down, 16.73 BTC had arrived. Another 1.73 BTC came in across 246 transactions after the alert, from servers that were still running [15].
Where the coins went
The address has made 19 payments, nearly all following the same pattern [15]. It bundles a batch of deposits, sends a round or near-round amount to a fresh address and keeps the change. That moved 18.43 BTC to 18 addresses, including one that received 5.5 BTC and another that got 4.71 BTC [15].
Sixteen of those 18 still held exactly what they received, 17.9 BTC in all, and had never spent [15]. The other two date from October 30. One passed its 0.36 BTC to another new address that hasn't moved, and the other split 0.175 BTC between an idle address and a 0.02 BTC payment that ended up at an address active since July, which we could not attribute [15]. About 0.028 BTC remained at the attacker's own address [15].
None of the destinations carried an exchange label in the public sources we checked. Dorier also posted a Litecoin address for the attacker, which this analysis does not cover [16].
BTCPay has yet to publish its technical write-up [6]. On-chain, the open question is when those 16 addresses start to move, and where. Self-custody tools have run into versions of the same problem since late October, from Electrum to Keystone, and the part of custody handed to always-online software is the part most worth watching.
Sources
Source type in brackets. All times UTC. Accessed November 2, 2026.
- BTCPay Server, post on X, 22:25 UTC on November 1, 2026. Shutdown request with
./btcpay-down.sh; over 600,000 views when checked. (Primary, project) - BTCPay Server, post on X, 04:07 UTC on November 2, 2026. Attack vector on 2.4.1 (Jul 23, 2026) or older, no credible reports on 2.4.7, security@btcpayserver.org. (Primary, project)
- BTCPay Server, post on X, 04:07 UTC on November 2, 2026. Automatic shutdowns by hosting providers, thanks to LunaNode. (Primary, project)
- Nicolas Dorier, post on X, 00:28 UTC on November 2, 2026. Public servers on 2.4.7 not attacked, reports on pre-2.4.2, attacker logged in as admin. (Primary, project founder)
- Nicolas Dorier, post on X, 01:52 UTC on November 2, 2026. Traces of pre-2.4.2 vulnerabilities. (Primary, project founder)
- Nicolas Dorier, post on X, 04:10 UTC on November 2, 2026, and reply, 04:22 UTC. No reason to panic if updated at least once since 2.4.2; don't keep too much in a hot wallet; blog post announced. (Primary, project founder)
- CoinDesk, BTCPay, a bitcoin payment tool, tells users to switch off their servers after reports of drained wallets, Omkar Godbole, November 1, 2026 (New York time). How hot wallets sign automatically and the documentation's "DANGER" label. (Secondary, press)
- BTCPay Server, Security Advisory: Update BTCPay Server to 2.4.2 Immediately, August 7, 2026. LND credential flaw, on-chain wallets not affected at the time, version check and update path. (Primary, project)
- BTCPay Server, 2.4.7 release notes, GitHub, October 29, 2026. 85 findings fixed, one critical. (Primary, project)
- Cointelegraph, BTCPay Server warns of hot wallet thefts running on outdated software, November 2, 2026. No count of affected operators or losses. (Secondary, press)
- BeInCrypto, Is Your BTCPay Server Safe? What the Hot Wallet Drain Investigation Shows, November 2, 2026. (Secondary, press)
- BTCPay Server, BTCPay Server Security Incident: Our Response and Next Steps, August 2026.
btcpay-update.sh, reporting to authorities and exchanges, cold storage. (Primary, project) - Nicolas Dorier, reply on X, 04:11 UTC on November 2, 2026 ("Not only the seed, they should consider the server cooked"). (Primary, project founder)
- Nicolas Dorier, post on X with the attacker's address, 04:13 UTC on November 2, 2026, linking to bc1p0f7w…63r7 on mempool.space. (Primary, project founder)
- mempool.space, our own read of the attacker's address (586 transactions) and its 18 destination addresses and next hops, 07:44 UTC on November 2, 2026; last confirmed activity in block 974,229 (07:35 UTC), first deposit in block 973,827 (13:35 UTC on October 30). Price of $77,984 from the mempool.space API at 07:40 UTC. (Primary, on-chain)
- Nicolas Dorier, post on X with the Litecoin address, 04:44 UTC on November 2, 2026. (Primary, project founder)
- Nicolas Dorier, reply on X, 01:00 UTC on November 2, 2026. Not a new vulnerability; "Don't put more than you are ready to lose in hot wallet." (Primary, project founder)
- Nicolas Dorier, reply on X, 03:22 UTC on November 2, 2026, on running his own 2.4.7 server with a hot wallet. (Primary, project founder)
More in Privacy and self-custody
Last updated: November 2, 2026
