BTCPay Server is one of the few pieces of self-hosted software that a lot of independent vendors actually rely on. It takes Bitcoin and Lightning payments without a processor in the middle, which is why it turns up in shops that would rather not explain their revenue to anyone. On 1 November, someone started draining hot wallets on it.
BTCPay disclosed the incident the next day. The attacks targeted installations running 2.4.1 or earlier. The project says the attackers used a different method to exploit the vulnerability that was fixed in 2.4.2, which shipped on 7 August. It has not published the technical details yet. What it has confirmed is that Bitcoin and Litecoin were stolen from hot wallets, meaning wallets whose spending keys live on the server itself.
Bitquery, which traced the funds, counted about $1.63 million across Bitcoin and Litecoin addresses linked to the thefts, according to reporting by Infosecurity Magazine. The same analysis counted 682 sweeps between 30 October and 2 November, including 267 after BTCPay's warning went out on 1 November. That last number is the ugly one. A lot of operators did not update, did not see the warning, or did not act on it quickly enough.
What BTCPay has confirmed
The timeline is short. At 13:46 on 1 November, a wallet drain matching the incident reports took place. At 20:56, BTCPay received the first email reporting a theft. That evening it contacted VPS providers, including LunaNode, and asked them to take BTCPay instances offline as a precaution. At 22:25 it warned the community on X and told operators to shut down their servers while it investigated.
The project's advisory for 2.4.2 describes the original vulnerability as an unauthenticated remote path to LND's .macaroon credential files. Those credentials could be used to control an LND node and move funds. In August, BTCPay said on-chain hot wallets were not affected and that only LND was at risk. The November incident changed that conclusion: the attackers found another way to use the same underlying flaw against on-chain wallets on older versions.
That distinction matters for anyone trying to work out whether they were exposed. The August advisory is not the whole story anymore. If you ran 2.4.1 or earlier with hot wallets on the server, you were in the target set regardless of whether you used LND.
Updating is not the same as cleaning
This is the part BTCPay is being unusually direct about. Updating alone cannot remove access an attacker may already have gained. An unchanged wallet balance does not prove you were not hit earlier. The project's recovery guidance says affected operators should rebuild on a fresh server with new wallets and seeds, not just apply the patch and carry on.
The reason is straightforward. If someone had administrative access to the host, patching the application does not evict them. They can have added keys, cron jobs, users or a modified binary. BTCPay is telling operators to treat the server as compromised and start over. That is expensive and annoying, and it is the correct response.
There is one piece of good news. Wallets whose spending keys are held off the server, including hardware wallets, were not affected by these thefts. BTCPay has recommended that setup for a while. If you were accepting payments straight into a hardware wallet and only keeping a small operational float on the server, your exposure is limited to that float. If the server held the keys to everything, it did not.
What to do if you run BTCPay
Check the version at the bottom of the login page. If it is 2.4.1 or earlier, assume the host is compromised. Take it offline, rebuild it from scratch, generate new wallets and seeds, and move any remaining funds to a wallet whose keys are not on that machine. Do not reuse the old seed. Do not restore the old server image and call it clean. Rotate any API keys, macaroons, SSH keys and passwords that were stored on it.
If you are already on 2.4.2 or later, you are outside the targeted versions, but the same hygiene applies: keep only working capital on the server, keep the rest on a hardware wallet, and install updates when they land. BTCPay's own note asks users to be diligent about updates because automated attacks are getting faster. The 267 sweeps after the warning are a decent argument for that.
For the wider scene, this is a reminder that payment infrastructure is its own attack surface. A vendor can do everything right at the market level, use PGP, verify links, avoid phishing, and still lose funds because the box running the checkout software was months behind on patches. BTCPay is not a darknet-specific tool, but it is popular with people who prefer to hold their own keys, and that is exactly the group this hit.
BTCPay is asking affected users to email security@btcpayserver.org with transaction details and to report the theft to local authorities. It also has a recovery bounty: 10% of recovered funds, capped at 3 BTC. Do not send seed phrases, private keys or passwords when reporting.