BTCPay Server 2.4.1 thefts: Rebuild, not just update

Attackers drained Bitcoin and Litecoin from hot wallets on BTCPay Server 2.4.1 and earlier. The project's recovery guidance is blunt: spin up a fresh server with a new wallet, don't just update. The vulnerability was patched in 2.4.2; the current push is for 2.4.7. Log in, scroll to the page footer, and read the version there before you decide between an update and a full rebuild.

For merchants running this self-hosted processor, the exposure goes past the wallet balance. A hot wallet leaves spending keys on the box; once unauthorized access is suspected, operators should treat the machine and every secret it holds as compromised. The Hacker News places the first theft reports around 1 November 2026. The project still hasn't nailed down when exploitation actually started.

Read the footer, then check your history

Log in to BTCPay Server and note the version at the bottom of the page. Now figure out what version was running when the project sounded the alarm on 1 November. The version you see today doesn't settle the recovery call — the project explicitly includes operators who updated an old installation after that warning.

Why an August patch drives November's rebuild order

The relevant fix predates the reports. BTCPay Server shipped 2.4.2 on 7 August 2026 to close the vulnerability, then pushed more security updates through August–October — 2.4.4 and 2.4.5 among them. The investigation says attackers used a different method to exploit the same flaw that 2.4.2 already fixed.

A wallet drain logged in the incident reports hit at 13:46 UTC on 1 November. The project's first theft-report email arrived at 20:56 UTC; the public warning went out at 22:25 UTC, telling operators to shut down while they investigated. By 2 November they'd identified 2.4.1 and earlier as the targets.

There was another security update in the same window. BleepingComputer notes that the emergency 2.4.7 release followed an October 29 disclosure of a critical vulnerability found via Anthropic's Frontier OSS scanner. The October 29 disclosure and the emergency 2.4.7 release do not prove the newly disclosed flaw caused these thefts.

The Hacker News leaves the link to the August vulnerability uncertain. The project's own investigation is more specific: it identifies a different exploitation method against the vulnerability fixed in August. That primary account drives the recovery paths above.

Rebuilding BTCPay Server 2.4.1 means new machine, new wallet, new credentials

Moving a 2.4.1 installation to a fresh machine isn't permission to carry the old wallet seed across. The project says reusing that seed leaves funds at risk. Its recovery guidance also explains why a normal update won't cut it:

“An unchanged wallet balance does not rule out an earlier attack.”

— BTCPay Server's security incident report

Follow the project's recovery sequence for an affected installation or any installation showing theft or unauthorized access.

1. Create a new wallet with a new seed on a trusted device. Sweep any remaining funds from the existing hot wallet into it. Do not reuse the old seed when preparing the replacement server.

2. Take the old server offline. Preserve relevant logs and transaction records for the investigation before replacing it. Those records also help when reporting the incident to the project.

3. Provision a fresh virtual machine. Install the latest supported BTCPay Server release from trusted sources and connect the new wallet. Do not restore the entire old server onto the replacement machine.

4. Revoke and replace potentially exposed passwords and access keys from a trusted device. Include applicable hosting, SSH, application, API and Lightning credentials that the old server could access. Do not enter replacement credentials on the old machine.

My take: a new machine doesn't change the project's warning about an old seed or exposed credentials.

Update if you're clean, but don't mistake it for recovery

For an installation already on 2.4.2 or later when the warning landed, the project reports no observed impact from these attacks. I'd say operators should still install current security updates. BleepingComputer gives the dashboard route as Server Settings → Maintenance → Update and names 2.4.7 as the target.

For a Docker installation, log in over SSH and run these commands to enter the root shell, switch to the deployment directory and execute the update script.

sudo su -
cd btcpayserver-docker
./btcpay-update.sh

Afterward, log in and check the version at the bottom of the page again. Checking the version confirms the update, not recovery from compromise.

Do not use this procedure as the entire recovery for a BTCPay Server 2.4.1 installation that was still on that version when the warning arrived. Updating after the warning does not remove the project's recommendation to rebuild.

Off-server keys protect funds, but the old host still needs replacement

Wallets whose spending keys lived off the server — hardware wallets included — were unaffected by these thefts, according to the project. Accepting payments into those wallets remains its recommended practice. However, the recommendation to rebuild an older server still applies even when its wallet keys were kept elsewhere.

For a merchant that doesn't need server-held spending keys, I'd choose the off-server arrangement. If daily operations require a hot wallet, the project recommends keeping only the funds needed for those operations on the server and moving the rest to a wallet with spending keys held elsewhere.

The investigation also has boundaries. The project says it has no credible reports of hot-wallet drains from users running the latest 2.4.7 release; that's a statement about reports received, not a blanket guarantee. It hasn't established the full attack timeline, and the published destination addresses' balances and histories aren't a confirmed total of losses.

Report theft without leaking more secrets

If funds were stolen or unauthorized activity appeared, email security@btcpayserver.org. The project asks for information that connects the installation's history with the transactions:

• The version running at the time, when it was last updated and the previous version, if known.
• When the incident was noticed, including the timezone.
• Relevant public transaction IDs and addresses.

Never send seed phrases, private keys, passwords or other credentials. Strip secrets from logs and configuration files before sharing them. If funds were stolen, the project also asks operators to report the theft to local authorities.

My priority would be to establish which recovery path applies before treating an update as closure. My take: for an exposed older installation, the practical endpoint is a fresh host, a new wallet seed and replaced credentials — not merely a newer version number.