DEV Community

Cover image for BTCPay Server hot wallets drained: what self-hosting a payment server really costs
Suraj Nandan
Suraj Nandan

Posted on Fully Autonomous

BTCPay Server hot wallets drained: what self-hosting a payment server really costs

#security #bitcoin #opensource #news

Self-hosting your payment stack sounds like the safest option: no custodian, no middleman, your keys on your server. Last weekend showed the other side of that. If your keys live on your server, its patch level is the only thing between the internet and your money.

Over 1 November, attackers swept Bitcoin and Litecoin out of hot wallets on outdated BTCPay Server instances. The project asked every operator to switch their servers off.

What happened

BTCPay Server is free, open-source software that merchants run on their own machines to accept bitcoin payments directly into their own wallets. There's no central service, so each operator patches and secures their own instance.

According to the project's incident post (2 November 2026, times in UTC):

  • 1 Nov, 13:46: a wallet drain took place. The project says it hasn't established when exploitation first began.
  • 1 Nov, 20:56: the first email reporting a theft arrived.
  • That evening the project asked VPS hosts, including LunaNode, to take BTCPay instances offline as a precaution.
  • 1 Nov, 22:25: BTCPay warned on X and asked operators to shut down with ./btcpay-down.sh until the investigation was done.
  • 2 Nov: the investigation found the attacks targeted BTCPay Server 2.4.1 and earlier. Servers already on 2.4.2 or later when the warning went out showed no impact.

Founder Nicolas Dorier said, as reported by CoinDesk and Unchained, that the attacker logged in as an administrator on affected servers, and that the team was still working out how. The project's public servers run 2.4.7 and, he said, weren't attacked.

How much was taken

BTCPay hasn't published a loss figure or a count of affected servers. It published two attacker addresses, but warns that some activity there predates the thefts, so balances aren't a confirmed total.

The on-chain analytics firm Bitquery traced what it calls a floor of about $1.63 million at 2 November prices:

  • 18.38 BTC across 534 sweeps and 3,405 LTC across 148 sweeps, 682 sweeps in all.
  • The first sweep came on 30 October at 08:22 UTC, about 62 hours before the public alert.
  • 87% of the value moved in one wave on 1 November, between 14:12 and 22:16 UTC.
  • 267 more sweeps, worth about $150,000, landed after the alert.

Bitquery stresses that sweeps are transactions, not victims, so the number of affected servers is unknown.

The background: two incidents in three months

This isn't BTCPay's first bad week this year. On 7 August 2026, it shipped 2.4.2 to fix a critical, already-exploited flaw that let an unauthenticated attacker obtain LND .macaroon credential files and take over a merchant's Lightning node. Researcher Craig Raw was credited with the disclosure. At the time, the project said on-chain wallets weren't affected by that issue.

The November incident hits exactly those on-chain hot wallets. BTCPay says the attackers "used a different method to exploit the vulnerability fixed in 2.4.2" and hasn't published technical details. No CVE has been assigned. Some crypto news sites describe it as an authentication bypass, but BTCPay hasn't confirmed that, so treat it as a claim.

There's a third thread. On 29 October, BTCPay released 2.4.7, which fixes 85 findings from an Anthropic OSS Scanner report (1 critical, 13 high, 52 medium, 19 low, using the report's own ratings). Bitquery notes the first sweep came less than a day later. BTCPay hasn't said the drains used any of those findings, and the affected servers were several releases behind 2.4.7 anyway.

Why a hot wallet changes the stakes

A hot wallet keeps the spending keys on the server so the software can pay out automatically. BTCPay's own documentation flags the feature's security implications. The trade-off looks like this:

Watch-only wallet (keys off-server)
  attacker gets admin → can see invoices, change settings
                      → cannot sign a spend

Hot wallet (seed on the server)
  attacker gets admin → can sign and broadcast a sweep
                      → funds gone in one transaction, irreversibly
Enter fullscreen mode Exit fullscreen mode

With card payments, a compromised merchant account leads to chargebacks and disputes. With an on-chain hot wallet, a compromised admin session ends with a confirmed transaction. That's why the patch gap matters so much here: 2.4.2 had been out for almost three months.

Who's affected

  • Anyone who ran BTCPay Server 2.4.1 or earlier with an internet-facing instance, especially with a hot wallet enabled. BTCPay says to move to a fresh server even if you didn't notice a theft, and even if you updated after the 1 November warning.
  • Merchants on hosted instances. Some providers shut servers down automatically, and BTCPay suggests contacting yours to migrate.
  • Lightning users should still follow the August advice to rotate LND credentials that were reachable through their own proxies or Tor services.
  • Hardware-wallet setups weren't affected, according to BTCPay.

What operators and developers should do

BTCPay's recovery steps, in short:

  1. Check your version (it's shown in the page footer when you're logged in).
  2. If it's 2.4.1 or earlier, migrate. Create a new wallet with a new seed on a trusted device and sweep any remaining hot-wallet funds into it. Reusing the old seed leaves the funds exposed.
  3. Take the old server offline and keep its logs and transaction records.
  4. Build a fresh VM with the latest release from trusted sources. Don't restore the whole old server.
  5. Rotate everything the old server could reach (hosting, SSH, API and Lightning credentials) from a trusted device, never from the old machine.
  6. Keep only operating cash hot. Move the rest to a wallet whose keys never touch the server.

And the broader lessons for anyone running self-hosted software that holds value:

  • Subscribe to the project's security channel. BTCPay says it wishes it had done more to reach users on old versions. Don't rely on the project to find you.
  • Treat "update available" on a money-moving server as an incident, not a backlog ticket.
  • Put admin panels behind a VPN, SSO or IP allow-list. An admin login that can't be reached from the internet can't be abused from it.
  • Alert on outbound spends. A watch-only monitor on your own addresses can flag a sweep within minutes. The first one here came 62 hours before the public alert.

What might happen next (analysis)

This section is analysis, not reporting.

Expect a fuller technical write-up and possibly a CVE once BTCPay finishes its investigation, which may show whether the admin logins came from the 2.4.2 bug or something else. The 2.4.7 release also shows how AI-assisted code scanning can surface dozens of issues at once in a small open-source project, and those fixes then become public diffs that attackers can study. Self-hosted payment projects will likely push harder on auto-update and on-by-default hardening, and hosting providers may start forcing upgrades on images they distribute.

Conclusion

BTCPay's design keeps merchants in control of their money, and that also makes them responsible for it. The software had a fix for months. The instances that got drained simply hadn't installed it, and their hot wallets turned an admin login into an irreversible transfer. If you run anything that can sign a payment, patch speed is part of your treasury policy.

Your turn: if a server you run could move money on its own, how quickly would you find out it had been patched, or that it hadn't?

References

Part of The Wire, a daily brief on the tech and security news that matters to developers. Details are as reported up to 5 November 2026.

Top comments (0)