On November 2, 2026, BTCPay Server asked operators to switch off their instances while it investigates reports of hot wallets drained by unauthorized attackers. Early information points to versions prior to 2.4.2, but the project has not yet quantified losses or the number of affected servers.
🔑 Key takeaways
- The project asks operators to stop every instance with the btcpay-down.sh command until the investigation ends.
- Founder Nicolas Dorier points to versions prior to 2.4.2; public servers running 2.4.7 were not attacked.
- An attacker logged in with administrator rights, and the access method is still unknown.
- No stolen amount, server count or patch has been disclosed so far.
An alert with no confirmed scope
In a post on X the previous day, the project told operators to shut down any active instance. The message left little room for interpretation:
“We are receiving reports of hot wallets on BTCPay Server instances being drained by unauthorized attackers. If you run an instance, please shut it down with the command btcpay-down.sh until we complete the investigation.”
BTCPay Server, post on X
The message did not specify how much money had been stolen or how many servers were affected. It announced no patch, no affected version and no restart date. The instruction therefore applied to every installation, since no perimeter had been established. The command stops the BTCPay Server software, which operators must keep disabled for the duration of the probe.
BTCPay Server is open-source, self-hosted software that lets merchants accept bitcoin payments. No custodial intermediary holds the funds. Each merchant runs its own instance, connects its own wallets and bears responsibility for its infrastructure, including internet-exposed servers and hot wallets.
What the founder said two hours later
About two hours after the initial alert, Nicolas Dorier, the project’s founder, provided more detail. He said the theft reports “appear to involve BTCPay Server versions prior to version 2.4.2“. He also said an attacker had logged in as an administrator on the targeted servers, and the team does not yet know how that access was obtained.
“The public servers of the project, which run version 2.4.7, have not been attacked.”
Nicolas Dorier, Founder, BTCPay Server
That statement covers only the project’s public servers. It does not mean that every installation running a newer release has been confirmed safe. No indicators of compromise that would let an operator check a specific instance have been published.
August 2026: a flaw already patched in 2.4.2
An earlier incident had been reported on August 7, 2026. The project then warned on its official X account that a “critical vulnerability is being actively exploited” in BTCPay Server, which could lead to loss of funds, and asked administrators to install version 2.4.2 immediately.
According to CoinDesk, the August flaw allowed an external attacker to retrieve LND credential files. LND is the software that runs a node on the Lightning Network. With those files, the attacker could take control of the node and move its funds. Administrators were given the following procedure:
- Open the administration dashboard.
- Go to Server, Maintenance and Update.
- Confirm that the version number shown at the bottom of the interface is 2.4.2.
- Shut down the server if the update cannot be applied immediately.
At the time of the August alert, crypto.news noted that BTCPay had not specified which older versions were vulnerable, how attackers entered servers, how many were compromised, or whether losses had been confirmed. In November, the provisional assessment does point to versions before 2.4.2. That change in precision does not by itself establish a formal contradiction, especially since the November alert concerns new reports. The available sources do not say whether the two incidents use the same technique.
Hot wallets: a structural risk surface
The official user guide distinguishes several ways to receive payments. With a hot wallet, the private key stays on the server, and signing can be automated using the recovery phrase stored on that same machine. The documentation flags this feature with a “DANGER” label and warns that it “comes with security implications”.
“automatically use the recovery phrase stored on a server to sign”
BTCPay Server, official user guide
In practice, a compromised server can send funds without validation on another device. The guide also states that a hot wallet exposes funds if the account or the server is compromised. The table below summarizes the three configurations the guide describes:
| Setup | Private key | Main risk |
|---|---|---|
| Hot wallet | On the server | Immediate loss if the server is compromised |
| Connected existing wallet | Off the server | Exposure limited to public data |
| Watch-only wallet | Absent from the server | Signing requires the seed phrase or an external signer |
Connecting an existing hardware or software wallet is presented as the normal choice when funds must be received into a wallet already in use. The guide also recommends enabling two-factor authentication, storing recovery codes offline, verifying addresses on a trusted device, testing recovery and signing before accepting large sums, and never entering an existing recovery phrase on an internet-connected server.
This architecture explains the call for a manual shutdown. Users manage their stores and wallets, while operators deploy instances, maintain the database and network services, run backups, apply updates and investigate server-wide failures. Because BTCPay does not act as a payment intermediary, there is no central switch to stop every compromised installation. Each host must act on its own.
Version 2.4.0 and the wider ecosystem
Version 2.4.0, released before the 2.4.2 fix, introduced passkey-based passwordless login, a guided setup for multisignature wallets, manual signing-key entry or entry through BTCPay Server Vault, and finer wallet permissions. The Greenfield API now distinguishes between viewing data, creating, signing and broadcasting transactions, and changing wallet settings. The same release upgraded LND from 0.19.3 beta to 0.21.0 beta, Core Lightning from 25.05 to 26.06.1 and phoenixd from 0.6.3 to 0.8.0. Its release note warned that the newer Core Lightning and LND versions did not work properly with BTCPay Server 2.3.9 because of outdated routes, and advised Lightning users to move to 2.4.
Nicolas Dorier created the software in 2017 after disagreements with BitPay over the SegWit fork and the B2X alternative to Bitcoin. According to STOKR, it can be self-hosted, supports hardware wallets and allows direct payments without processor fees, but each merchant remains responsible for its own server. The Elestio quickstart guide describes BTCPay as a decentralized, open-source payment system, and no source reports that instances hosted by Elestio or another provider have been affected.
More broadly, the volunteer group Bitcoin Red Team identified 4,962 potential issues across 390 bitcoin-related projects, of which 720 were classed as serious or critical. It publicly named no unresolved critical flaw. No link has been established between that review and the BTCPay incidents, and no measurable market reaction is reported: no price, volume or aggregate loss figure has been published.
Scenarios and watchpoints
As of the latest available information, the operational response is to stop every instance with btcpay-down.sh and keep them offline until the investigation concludes. The immediate-update instruction to 2.4.2 applied to the August alert. For November, BTCPay has published no patch, no restart date, no loss estimate and no general confirmation that recent versions are safe.
Three outcomes are possible. If the investigation confirms a flaw limited to versions before 2.4.2, a restart could rely on a targeted update and the publication of indicators of compromise. If the access method remains unknown, the perimeter could widen beyond the identified versions, prolonging the shutdown. Finally, an intrusion based on stolen credentials or poor recovery-phrase handling would show that security depends as much on operational practice as on the software itself.
For merchants, the priorities are clear: verify the installed version, remove any recovery phrase from an exposed server, and limit the amount held in hot wallets. The true size of the affected funds remains unknown.
Sources
- CoinDesk, November 2, 2026
- BTCPay Server official user documentation
- STOKR, BTCPay overview
- Elestio, BTCPay quickstart guide
- BTCPay Server blog, version 2.4.0
- crypto.news, BTCPay Server August 2026 alert
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
