Writing · November 2026
The server held the keys.
Attackers logged in as an administrator on older BTCPay Server instances and moved the Bitcoin out. The wallet's keys lived on the same internet-facing machine, so nothing stood between the login and the money.
On Sunday, November 1, BTCPay Server posted a warning on X. Per CoinDesk, it read: "We are receiving reports of hot wallets on BTCPay Servers being swept by unauthorized attackers. If you're running an instance, please shut it down (./btcpay-down.sh) until we complete the investigation." This story is a day or two old and the investigation is open. I'm going to say what the reporting supports and mark where it stops.
What the sources agree on
BTCPay is an open-source Bitcoin payment processor that merchants run on their own servers. About two hours after the first alert, CoinDesk reports, founder Nicolas Dorier added that an attacker had logged in as an administrator on the affected servers. He said the reports "appear to involve BTCPay Server releases older than version 2.4.2."
The project later narrowed that. BleepingComputer and Cointelegraph both quote the maintainers identifying an attack vector against instances running 2.4.1 or earlier. They also report "no credible reports of hot wallet drains" for users on 2.4.7, and that the guidance moved from shut it down to update and take old instances offline. BleepingComputer says the attacker made unauthorized payments from those instances.
BTCPay's public servers, which run 2.4.7, were not attacked, CoinDesk reports.
What nobody has said
The cause. All three outlets say how the attacker got administrator access is unknown. BleepingComputer says its request for details went unanswered, and Cointelegraph says the same.
The losses. No amount has been published. Neither has a count of affected servers or operators.
The link to other events. In August, BTCPay disclosed a separate flaw that exposed credential files for Lightning nodes. Cointelegraph says it's unclear whether the new attack is connected. Version 2.4.7 came out October 29, per the project's release notes, but nobody has said whether those fixes touch this attack, so I won't guess.
The dates. CoinDesk puts the first alert on Sunday, November 1. Some outlets carry a November 2 date. I'm using the date CoinDesk gives for the alert and noting the difference.
The part that isn't news
CoinDesk notes that BTCPay's own documentation labels the hot wallet feature with a "DANGER" warning. The reason is simple. A hot wallet keeps the seed on the same internet-facing server that processes payments. That server can sign and send with no second approval. Whoever gets administrator access on that machine holds the keys, because the machine holds the keys.
None of the reporting says that design caused these thefts. The cause isn't known. But it's why a login problem became a money problem.
I've spent years teaching people to put distance between a key and anything that touches the internet. A carpenter doesn't leave the saw plugged in and running on the bench overnight, even in a locked shop. The lock is the shop's job. Switching the saw off is yours.
What I'd do
1. If you run an instance, check your version. The project's guidance, per BleepingComputer, is to update to 2.4.7 (Server Settings, Maintenance, Update, or ./btcpay-update.sh for Docker) and to take 2.4.1 or older offline as soon as possible. Follow the project's own channels over mine, because this is moving.
2. Don't wipe the server if you've been hit. BTCPay asks affected operators to send details and logs to [email protected], per BleepingComputer. Those logs are how the cause gets found.
3. Keep a float, not a treasury, in any server wallet. Hold only what you'd be willing to lose if the server were fully compromised tonight. Everything else belongs on a device that never touches that machine.
4. Prefer a watch-only setup. The Coin Republic notes that BTCPay supports connecting an external wallet by extended public key, which keeps the private keys off the server. A stolen administrator login then sees addresses, not spending power.
5. Treat "my version is old" as an incident. Self-hosting means you are the sysadmin. Old software on a server holding spendable keys is a standing risk. Version 2.4.2 shipped in August, per the release notes, and the affected range is everything before it.
The boring conclusion
Self-hosting is the right instinct. It's the same instinct behind holding your own keys. But hosting something yourself moves the patching, the login hygiene and the blast radius onto you. The useful question isn't whether to trust the software. It's what an attacker gets if the software fails, and whether you've already decided how much that is.
This one is still developing. If BTCPay publishes a root cause, the story changes, and I'll say so.
Verify everything, especially the machine that holds your keys.
— Jon Tetreault, November 2026. The habits, tools, and checks behind this piece are what I teach in Crypto Security Mastery.