BTCPay Server 2.4.1 and Earlier Had Its Hot Wallets Drained. If You Self-Host One, Treat the Whole Server as Compromised and Move to a New Seed.
If you run BTCPay Server 2.4.1 (released July 23) or earlier, stop reading and take it offline. BTCPay's own incident post says Bitcoin and Litecoin were stolen from hot wallets on servers running those versions, starting November 1. Wallets whose spending keys are held off the server, including hardware wallets, were unaffected. Updating does not remove access an attacker already has, so the project's instruction is to build a new server, create a new wallet with a new seed, move the remaining funds and replace every credential the old server could reach.
What the project says
BTCPay's post, updated November 2, says the team asked hosting providers on November 1 to take instances offline as a precaution and warned the community at 22:25 UTC. A wallet drain occurred at 13:46 UTC on November 1, and the first theft report by email arrived at 20:56 UTC. On November 2 the team identified versions 2.4.1 and earlier as affected. It says the attackers used "a different method" to exploit the vulnerability that version 2.4.2 fixed on August 7, which is the earlier flaw that exposed Lightning credential files.
For anyone on 2.4.1 or earlier, the post says to take the old server offline, preserve its logs and transaction records, and provision a fresh server with the latest supported release. It says to create a new wallet with a new seed on a trusted device and sweep what remains, because reusing the old seed leaves those funds at risk. It also says to revoke and replace every credential the old server could reach, including hosting, SSH, application, API and Lightning credentials, and not to type new credentials into the old machine. If you were on 2.4.2 or later when the warning went out, the team reports no impact on those servers.
What nobody knows yet
The flaw. The project has not named it, and no CVE has been published.
How the attacker became an administrator. BleepingComputer reports that the investigation is focused on how the attacker logged in as an admin on pre-2.4.2 instances.
When it started. The project says some activity at the reported addresses appears to predate the thefts, so balances are not a confirmed loss total.
How much was stolen. No total has been published.
Who did it. No one has attributed it to an actor. The Binance theft got an attribution from the FBI within days, and this one has none.
The sources disagree on the latest version
BleepingComputer says the project urged users to move to version 2.4.7, and that a critical vulnerability disclosed October 29 led to an emergency 2.4.7 release. BTCPay's own post, as we read it, does not mention 2.4.7 and points to the latest supported release. Both say 2.4.1 and earlier is the exposed group. Be on the newest release either way, but do not treat an update as a cure for a server that was already on 2.4.1.
What to do
Check your version first. If it is 2.4.1 or earlier, take the server offline now and preserve the logs.
Build a new server and a new wallet. Generate the new seed on a trusted device, not on the old machine, then sweep the remaining funds into it.
Replace every credential the old server could reach, from a trusted device.
Move to the latest release. In the web interface that is Server Settings, then Maintenance, then Update. On Docker installs, BleepingComputer says to run the btcpay-update.sh script from the btcpayserver-docker folder.
Report it. The project asks for your BTCPay version, when you last updated, when you noticed the incident with your time zone, and relevant public transaction IDs and addresses, sent to [email protected]. Never send seed phrases, keys or passwords. If funds were stolen, report to local authorities too.
What we do about it, and what we cannot
We are not a news site, so here is where we stand, as of this writing.
There is nothing to block. No flaw or CVE has been named, and our KEV index has no BTCPay entry, so there is no exploit path to look for at our edge. We have not run an edge check, because there is nothing to search for yet.
Our feed does not carry wallet addresses. It carries IPs, domains and file hashes. BTCPay's post lists one Bitcoin and one Litecoin address. We are not republishing them, because the read we have does not make clear whether they are the thieves' or victims' wallets, so read them in the project's post.
Your server is not behind our edge. Self-hosted BTCPay servers are yours. If your server was reachable from the internet, your protection is the steps above.
We will update this post if the project names the flaw or publishes indicators, and we will ingest any attacker infrastructure the same day.
Free API keys for our blocklist feed are open to anyone, and the day indicators exist, they are the first thing to go in.
Limits
The incident details come from BTCPay's own post and a BleepingComputer article, both read through a summarizing tool and not line by line. We did not verify the addresses or any on-chain movement, and we cannot confirm the 2.4.7 details. A last disclosure: Anthropic makes Claude, which we use to help write these posts, and BleepingComputer says an Anthropic scanner found the October 29 flaw.
Five percent of this is wrong somewhere. It always is.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments