> ## Content Index > Fetch the complete content index at: https://blog.harshkohli.com/llms.txt > Use this file to discover other available public pages before exploring further. # BTCPay Server Hot Wallets Drained: Check and Update Now - URL: https://blog.harshkohli.com/btcpay-server-hot-wallet-attack-check-update/ - Published: 2026-11-02T09:34:46.000Z - Updated: 2026-11-11T09:42:23.000Z - Description: Attackers are emptying hot wallets on old BTCPay Server installs. Here's how to check your version, update to 2.4.7 and tell whether someone got in. - Author: Harsh Kohli - Tags: How-To, Fixes, Software *Updated 2 November 2026\. Checked against BTCPay Server's own posts on X, its GitHub releases and its security advisories this afternoon. I'll update this post when BTCPay publishes its full write-up.* Short answer: if you run your own BTCPay Server and you haven't updated since early August, someone may already have been inside it. Late on 1 November, BTCPay warned that hot wallets on self-hosted instances were being emptied and told operators to shut down until it knew more. A few hours later it narrowed things down: the attack targets **version 2.4.1 or older**, and it has no credible reports of drains on the current **2.4.7** release. So check your version, get onto 2.4.7, and if you were on an old build with a hot wallet, treat that server as compromised. I'm writing this one up because a lot of the people affected won't be big companies. They're small shops, freelancers and hobbyists who set up BTCPay on a cheap VPS a year ago and haven't logged in to the server since. If that sounds like you, here's how I'd work through it. **Jump to:** - [What happened](#what-happened) - [Step 1: Check which version you're running](#step-1-check-which-version-youre-running) - [Step 2: Take an old server offline first](#step-2-take-an-old-server-offline-first) - [Step 3: Update to BTCPay Server 2.4.7](#step-3-update-to-btcpay-server-247) - [Step 4: Check whether someone got in](#step-4-check-whether-someone-got-in) - [Step 5: If your hot wallet was swept](#step-5-if-your-hot-wallet-was-swept) - [Step 6: Keep less in the hot wallet](#step-6-keep-less-in-the-hot-wallet) - [Which versions are affected (table)](#which-versions-are-affected) - [FAQ](#faq) ## What happened BTCPay Server is the free, open-source Bitcoin payment processor that merchants host themselves. Most setups don't hold keys on the server at all. The exception is the "hot wallet" option, where the wallet's seed is stored on the server so it can send funds without you signing each payment. BTCPay's own docs flag that option as dangerous for exactly this reason: whoever controls the server can spend the money. At 22:25 UTC on 1 November (03:55 IST on 2 November), the project [posted on X](https://x.com/BtcpayServer/status/2117020340815819262?ref=blog.harshkohli.com) that it was getting reports of hot wallets being swept by attackers and asked everyone running an instance to shut it down with `./btcpay-down.sh` until the investigation was done. About six hours later, it [followed up](https://x.com/BtcpayServer/status/2117106238123123008?ref=blog.harshkohli.com): the attack vector targets instances running 2.4.1, released on 23 July, or older, and it had no credible reports of drains for anyone on 2.4.7\. It also said some hosting providers, LunaNode among them, may have shut instances down automatically. Nicolas Dorier, who founded the project and still leads development, added a few details on X. The attacker logged in to affected servers as an admin, and there were traces of the vulnerabilities fixed back in 2.4.2 being used to get there. His advice for anyone who'd been swept was blunt: assume more than the seed is gone and consider the whole server "cooked". He also said that people who had updated at least once since 2.4.2 came out had no reason to panic, and that versions above 2.4.2 weren't hit. Nobody official has put a number on the losses yet. One on-chain tracker, cryptowatchdesk, counted about 18.76 BTC (roughly $1.47 million, or about ₹14 crore) and about 3,383 LTC (roughly $189,000, or about ₹1.8 crore) arriving at the addresses Dorier shared. That's a third party reading public data, so take it as an estimate. The background matters here. In August, [BTCPay's 2.4.2 advisory](https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/?ref=blog.harshkohli.com) fixed a critical bug that was already being used to steal LND admin credentials, plus a way around two-factor login through the API's Basic auth. The project's [incident follow-up](https://blog.btcpayserver.org/btcpay-server-security-incident-response-and-next-steps/?ref=blog.harshkohli.com) back then told everyone to update immediately. Nearly three months on, the servers that never did are the ones getting emptied. ## Step 1: Check which version you're running Log in to your BTCPay Server as an admin and look at the footer at the bottom of the page. It shows the version number. The 2.4.2 advisory uses the same check to confirm an update worked. - **2.4.7:** you're on the latest release. Skip to Step 4 and still give the server a quick look. - **2.4.2 to 2.4.6:** not the versions being targeted, but update anyway (Step 3), because 2.4.7 fixes a long list of other security issues. - **2.4.1 or older:** this is the risky group. Go to Step 2 now. If you can't log in at all, or your admin login suddenly doesn't work, that's a bad sign in itself. Jump to Step 5. ## Step 2: Take an old server offline first If you're on 2.4.1 or older and you hold a hot wallet, the project's first instruction still makes sense: stop the server before you do anything else. SSH in and run: ``` sudo su - btcpay-down.sh ``` That stops the whole Docker stack, so checkouts won't work for a while. That's annoying, but it's much better than an attacker keeping admin access while you read release notes. You can check what's running afterwards with `docker-compose -f "$BTCPAY_DOCKER_COMPOSE" ps`, which the [BTCPay operations docs](https://docs.btcpayserver.org/Docker/operations/?ref=blog.harshkohli.com) list along with the other lifecycle commands. If you use a hosted provider rather than your own VPS, check your provider's status page or email first. Some of them already switched instances off for you. ## Step 3: Update to BTCPay Server 2.4.7 There are two ways to update. If you can still reach the web interface, go to **Server Settings, then Maintenance, then Update**. If you've taken the server down or prefer the command line, use the update script from the [official updating guide](https://docs.btcpayserver.org/Docker/updating/?ref=blog.harshkohli.com): ``` sudo su - btcpay-update.sh ``` The script pulls the latest code, regenerates the Docker Compose files and recreates the stack, so it brings the server back up when it's done. ![BTCPay Server docs page showing the btcpay-update.sh command and the steps the update script runs](https://blog.harshkohli.com/content/images/2026/11/btcpay-docs.webp) The official "Updating" page, with the exact commands. Screenshot: docs.btcpayserver.org, BTCPay Server Foundation. When it finishes, log back in and check the footer again. It should read 2.4.7\. If it still shows an old version, run the update again. The project gave the same advice in August for anyone unsure whether an update took. 2.4.7 itself came out on 29 October. According to its [release notes](https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.7?ref=blog.harshkohli.com), it fixes 85 security findings reported through Anthropic's OSS Scanner program: 1 critical, 13 high, 52 medium and 19 low. That's separate from the attack on old servers, but it's another good reason not to stop at 2.4.2. ![GitHub release page for BTCPay Server 2.4.7 listing 85 security findings fixed by severity](https://blog.harshkohli.com/content/images/2026/11/btcpay-rel.webp) The 2.4.7 release on GitHub. Screenshot: github.com/btcpayserver, BTCPay Server Foundation. ## Step 4: Check whether someone got in Dorier said the attacker logged in as an admin. So even if your wallet balance looks fine, spend ten minutes on these checks. This part is my own checklist, not an official BTCPay procedure: - **Admin accounts:** look through the server's users and make sure every admin is someone you know. Delete or lock anything you don't recognise. - **Your own login:** change your password and turn on two-factor login if it's off. - **API keys:** revoke keys you don't use, and recreate the ones you do. That matters most if you ever enabled Basic auth for the Greenfield API, which 2.4.2 switched off by default because of the two-factor bypass. - **Wallet history:** look at the hot wallet's recent transactions for payments you didn't send. - **Logs:** `docker-compose -f "$BTCPAY_DOCKER_COMPOSE" logs --timestamps` shows the container logs with timestamps if you want to dig further. If anything looks off, don't just clean it up and carry on. Go to Step 5. ## Step 5: If your hot wallet was swept Take Dorier's advice literally and treat the whole server as compromised, not just the wallet seed. Here's what I'd do, in this order: 1. Leave the old server off. Don't reuse it, even after updating. 2. If any funds are left anywhere that seed controls, move them to a wallet created on a different device. 3. Build a fresh server on 2.4.7 with new admin passwords, new API keys and a new wallet. If you need a hot wallet again, give it a brand new seed. 4. Rotate anything else that lived on that box: SSH keys, exchange API keys, email or SMTP passwords, payment plugin keys in your shop. If you've never done a full rotation, my post on [rotating API keys after a breach](https://blog.harshkohli.com/railway-breach-rotate-api-keys/) walks through the order I use. 5. Report it. In August, BTCPay asked affected users to email [security@btcpayserver.org](mailto:security@btcpayserver.org) with on-chain addresses and transaction details, report the theft to local police, and contact any exchange the coins were traced to. That still seems like the right channel. Keep the transaction IDs of the sweep. Exchanges and police both ask for them, and having them early improves the odds of a freeze. ## Step 6: Keep less in the hot wallet The longer-term fix is boring but it works. BTCPay itself recommends keeping funds in cold storage whenever possible and regularly moving extra funds out of any hot wallet you need for daily operations. Dorier's version on X was simpler: update often and don't keep too much in the hot wallet. In practice, that means a watch-only wallet for receiving payments wherever you can, so the server never holds a seed at all. If you do need a hot wallet for refunds or payouts, keep only a few days' worth in it and sweep the rest to a hardware wallet on a schedule. And if updating the server is the job you keep putting off, set a monthly reminder. The servers that got hit this weekend were the ones still running builds from before early August. ## Which versions are affected | Version | Released | Status | | --------------- | ---------------------------- | ---------------------------------------------------------------------------------------------------- | | 2.4.1 and older | 23 July 2026 or earlier | Targeted in this attack. Take offline and update now. | | 2.4.2 | 7 August 2026 | Fixed the actively exploited LND credential bug and the 2FA bypass. Not reported as hit, but update. | | 2.4.3 to 2.4.6 | 24 August to 26 October 2026 | Not reported as hit. Update to 2.4.7. | | 2.4.7 | 29 October 2026 | Latest. No credible reports of drains, per BTCPay. | This is all still moving. BTCPay has said a blog post with more detail is coming, and I'll update this page when it lands. If crypto security is on your mind this week, the [Trezor implant warning](https://blog.harshkohli.com/trezor-cryptobilis-implant-warning/) and the [Binance withdrawal pause](https://blog.harshkohli.com/binance-hack-withdrawals-paused/) are worth a read too. For a different supply-chain style incident this week — Level Infinite CDN scripts in the NIKKE PC launcher — see [how to check for k2f\_chan and clean the Chrome DLL](https://blog.harshkohli.com/nikke-pc-launcher-malware-check-clean/). **Related guides:** two more from me that pair well with this one: [checking and patching the APT flaw CVE-2026-109518](https://blog.harshkohli.com/apt-cve-2026-109518-check-patch/) and [checking and patching the Linux TCP flaw CVE-2026-98432](https://blog.harshkohli.com/linux-tcp-cve-2026-98432-check-patch/). ## FAQ ### Is my BTCPay Server affected if I don't use a hot wallet? The money being stolen came from hot wallets, because that's where the seed sits on the server. A watch-only setup has no seed for an attacker to take. But Dorier said the attacker got admin access, and an admin could still mess with your store settings or payment details. So update and run the Step 4 checks either way. ### I'm on 2.4.2 or newer. Do I need to do anything? According to BTCPay and Dorier, versions after 2.4.2 weren't part of this attack, and there are no credible drain reports on 2.4.7\. You don't need to panic, but you should still update to 2.4.7 for its 85 security fixes. ### Does this affect people who just pay with Bitcoin at a BTCPay store? No. The attack hit merchants' own servers and the hot wallets on them. If you paid a shop through BTCPay, your wallet isn't involved. The store is the one that might have lost money. ### How much was stolen? There's no official figure yet. An on-chain tracker estimated about 18.76 BTC (around $1.47 million, or ₹14 crore) and about 3,383 LTC (around $189,000, or ₹1.8 crore) received by the attacker's addresses. Treat that as an estimate until BTCPay publishes its own numbers. ### Can I just update and keep using the old hot wallet? Not if it was swept or you see any sign of an intruder. Dorier's view is that the whole server should be treated as compromised, so build a fresh one with a new seed. If your server was on 2.4.2 or newer the whole time and nothing looks off, updating is enough. ### How do I get BTCPay Server to update automatically? BTCPay doesn't install updates silently. You run them from Server Settings, then Maintenance, or with `btcpay-update.sh`. The easiest habit is to check the footer version once a month and update whenever it's behind.