BTCPay Server warns older hot wallets were drained

BTCPay Server told merchants on November 2, 2026 that Bitcoin (BTC) and Litecoin (LTC) had been taken from hot wallets on servers still running version 2.4.1 or older, while those reports left the 2.4.7 release outside the drains the project had in hand. Readers who stopped at the August advisory will find the scope has moved. That note described an LND credential exposure fixed in 2.4.2 and placed on-chain hot wallets outside the impact, whereas the November investigation says attackers used a different method against the vulnerability fixed in 2.4.2 and emptied on-chain hot wallets.

The project laid the account out in its November 2 blog post. Investigators said the attacks targeted BTCPay Server 2.4.1, released on July 23, 2026, and every earlier build, by a different method of exploiting the vulnerability that version 2.4.2, published on August 7, 2026, had already closed. On X that morning the project account said it held "no credible reports of hot wallet drains for users running the latest 2.4.7 release." GitHub records 2.4.7 as shipping on October 29, 2026, three days before the first theft email.

What the timeline shows

The blog's UTC log places one reported drain at 13:46 on November 1, 2026, and the maintainers say they still lack a start time for the first exploit. The first email arrived at 20:56 UTC. Maintainers then asked virtual-private-server hosts, LunaNode among them, to take BTCPay Server instances offline. At 22:25 UTC the project account told operators to shut servers down while the investigation continued. A November 2 update named 2.4.1 and earlier as the affected set, and a companion post said LunaNode and other hosts had already powered instances down.

Related:GenLayer mainnet seats follow a points leaderboard

How hosts and maintainers responded

LunaNode, named in the posts and listed among supporters of the BTCPay Server Foundation, took instances offline after the project asked hosts to do so. The request went to the companies running the virtual machines, which fits software where each merchant keeps an instance, rather than to a custodial exchange with one omnibus wallet to freeze. Wallets whose spending keys stay off the server, hardware wallets included, sat outside these thefts, the project said, and rebuilding an older server remains the advice even when those keys live somewhere else.

Andrew Camilleri, posting as Kukks in the recovery note the project linked, wrote on November 2, 2026: "Please note that updating after the fact is not enough." He added: "Treat the entire machine as compromised." Operators on 2.4.1 or earlier, including anyone who updated only after the November 1 warning, were told to sweep remaining coins into a new wallet whose seed is created on a trusted device. The replacement is a fresh virtual machine on the latest supported release, with fresh hosting, SSH, application, API and Lightning credentials, and the project told operators to skip copying the old server across.

Why older builds stayed exposed

The stretch from the August 7 fix to the November 1 reports is what a custody desk can use. Release notes for 2.4.2 called the bug a critical vulnerability under active exploitation, and the August 7 advisory told anyone running LND to update immediately, confining the exposure to LND credential files and placing on-chain wallets outside that incident. The November post says the authors wished they had done more to reach people still on older versions, even after 2.4.4 and 2.4.5. Those later builds left 2.4.1 servers in production, which is why hosts were still powering boxes down roughly three months after the fix. Institutional write-ups treat off-server key control as the product, from Standard Chartered's Zodia Custody signing to Cactus Custody's Swiss launch and a Keystone shipping-data disclosure.

The blog names two destination addresses and warns that some activity appears to predate the thefts described so far. A mempool.space reading of the Bitcoin address on November 3, 2026 showed 759 transactions and about 20.31 BTC received, with about 0.0236 BTC unspent. Because the project said those histories mix older activity with the reports in hand, the sums stay an address record rather than a confirmed loss total.

Servers already on 2.4.2 or newer at the November 1 warning are the group the project said had shown no impact, and 2.4.7 is the build it singled out as free of credible drain reports. Instances still on 2.4.1 or earlier are the group told to assume compromise and move, and the project has left both the exploitation's start and any summed loss figure open.

This article is informational analysis only and is not financial, investment, or trading advice. Cryptocurrencies are highly volatile and can lose substantial value rapidly. Past performance and historical patterns do not guarantee future results. Do your own research and consult a regulated financial adviser before making any investment decision.