BTCPay Server wallet thefts: what happened and which versions are at risk

Reporting updated November 2, 2026. This article follows BTCPay Server's full incident advisory, which supersedes its initial precautionary shutdown alert.

BTCPay Server has confirmed reports of Bitcoin and Litecoin being stolen from hot wallets on outdated installations. Its November security advisory identifies versions 2.4.1 and earlier as the targets.

The distinction matters: this was not a failure of Bitcoin's consensus rules, nor does the advisory say every BTCPay wallet was drained. The reported thefts involved wallets whose spending keys were stored on affected servers.

A new attack method against an already patched vulnerability

According to BTCPay, attackers used a different method to exploit a vulnerability fixed in 2.4.2 on August 7, 2026. A new wave of thefts does not necessarily mean a new, previously unknown vulnerability.

The August advisory focused on exposed LND credentials and the risk to Lightning nodes. Its statement that BTCPay's own on-chain hot wallets were unaffected described the attacks reviewed then. It should not be carried forward as reassurance about November's hot-wallet thefts.

The latest stable release checked for this article is 2.4.7, published October 29. It predates the November warning. BTCPay says it has seen no impact from these attacks on servers already running 2.4.2 or later when the warning was issued. That is an observation about this incident, not a promise that any software version is invulnerable.

Why the location of your keys matters

BTCPay's user guide distinguishes three ways to connect a wallet:

• An existing wallet can supply public receiving information while keeping its private keys elsewhere.
• A watch-only wallet can track incoming payments without retaining the private key on the server.
• A hot wallet keeps the private key on the server so it can spend directly from the BTCPay interface.

The last option is convenient. It also puts spending authority on a machine exposed to the internet. BTCPay reports that funds with spending keys held off the server, including hardware wallets, were unaffected by these thefts. This does not mean a compromised payment server can be ignored: payment configuration, access credentials and customer-facing information still need investigation.

Updating may not be enough after a compromise

For a server that was running 2.4.1 or earlier, the current advisory recommends a fresh server and a new wallet, even if its balance looks unchanged or it was updated after the November 1 warning. An update can close a vulnerability without removing access an intruder already obtained.

If funds were stolen or there are signs of unauthorized access, treat the entire machine and its secrets as compromised and follow the same recovery process, even if the software has already been updated. Revoke and replace potentially exposed credentials from a trusted device. Never enter new credentials on the old server.

Operators should follow the project's full recovery instructions, rather than treat a blog checklist as a replacement for incident response. The approach is to protect remaining funds using a new seed created on a trusted device, preserve evidence, isolate the old machine, rebuild from trusted software and replace exposed credentials. Reusing the old seed or restoring the entire compromised machine defeats the purpose.

Lightning operators need additional care. BTCPay's Lightning documentation explains that a node has on-chain funds and off-chain channel funds. A seed backup alone does not recover the channel state. Do not erase a node or improvise a migration without checking the recovery requirements of its Lightning implementation.

What we still do not know

BTCPay has not established when exploitation first began or a confirmed aggregate loss total. It specifically warns against treating the balances or transaction histories of reported destination addresses as the amount stolen in this incident. We are not publishing a speculative loss figure.

Affected operators can contact security@btcpayserver.org with their version history, incident time and public transaction details. Never send a recovery seed, private key, password or access token. Remove secrets from logs before sharing them.

A practical lesson for merchants in Panama

For a shop, charity or online business accepting Bitcoin, someone must own the maintenance job. Agree who checks security releases, who can take checkout offline, and how the business will verify payments during an incident. A server installed once and forgotten is still an operating responsibility.

Keep payment infrastructure separate from long-term savings where possible. Decide what amount the business actually needs in a hot wallet, and test signing and recovery with small amounts before relying on the setup for meaningful revenue. Self-custody gives the operator control; it also leaves the operator responsible for the consequences of that control.

There is no evidence in the cited advisory that Panama Bitcoin or a particular Panamanian merchant was affected. This is a warning to check the setup, not a claim of local losses.

Follow the official BTCPay advisory for incident updates, and subscribe to Panama Bitcoin for more Bitcoin news and practical education.