BTCPay Server flaw: hot wallet thefts hit old versions

BTCPay Server reports Bitcoin and Litecoin thefts from hot wallets on version 2.4.1 and earlier. Its November disclosure says attackers used another method to exploit a flaw patched in August. A hot wallet keeps spending keys on the server.

BTCPay Server incident timeline

Dates are in 2026. Times are UTC. The project has not established when exploitation began.

• August 7: Fix released. Version 2.4.2 patches the vulnerability. August advisory
• October 29: Further security fixes. Version 2.4.7 addresses 85 findings from Anthropic’s scanner, including one rated critical. Release notes
• November 1, 13:46: Reported theft. A wallet drain later described to investigators occurs. Incident timeline
• November 1, 20:56: First email received. The team receives a theft report, then warns operators at 22:25 to shut servers down. Incident timeline
• November 2: Affected versions identified. The project names 2.4.1 and older and recommends rebuilding affected installations. Investigation update

The BTCPay Server flaw

The August advisory described an unauthenticated attacker obtaining LND macaroon files. These credentials authorize access to a Lightning node and can permit funds to move. That investigation focused on LND, including its own on-chain wallet. It did not identify BTCPay’s separate on-chain hot wallets as affected by the attacks reviewed then.

November’s account describes a different exploitation method against the same older vulnerability. Reading August’s narrower assessment as permanent protection for every wallet would miss that distinction.

The August follow-up confirmed stolen funds and said updating also regenerated LND’s admin macaroon. It urged operators to keep excess funds away from hot wallets. Updating software and replacing exposed credentials address different parts of recovery.

Update, then assess earlier exposure

The 2.4.7 release also fixes invoice access checks, authentication limits and payout handling. Its maintainers particularly recommend upgrading servers shared by several merchants. These October fixes should not be confused with the August patch implicated in November’s theft reports.

Check your version and update history before deciding that a current version proves the machine was never exposed. A successful update describes installed software, not everything that happened before installation.

For affected older servers, the project’s recovery instructions call for a new wallet seed, sweeping remaining funds, taking the old machine offline, preserving evidence and rebuilding on a fresh virtual machine. Replace exposed credentials from a trusted device. Do not restore the entire compromised server or reuse its wallet seed.

Keep spending authority separate

BTCPay’s wallet documentation explains that receiving payments can use an extended public key from an external wallet. Supported hardware wallets can also connect through its wallet interface. Receiving an invoice payment does not require placing the corresponding spending keys on the web server.

An extended public key helps generate receiving addresses without granting permission to spend. It still deserves care because it can reveal wallet activity. Keep the distinction clear when choosing a payment setup: the checkout server needs to recognize incoming payments, while spending can require a separate device. That separation reduces what a compromised server can do with its local files.

For Monero readers, the related lesson is to understand which machine can authorize a payment. The Monero recovery guide explains restoring wallets. A backup restores access, but cannot revoke a secret someone else copied.