BTCPay Server, the open-source software merchants use to accept bitcoin, warned on Nov. 1 that attackers were emptying hot wallets on servers running outdated versions. A follow-up on Nov. 2 narrowed the problem to version 2.4.1 and older and urged operators to move to 2.4.7. The project has not said how much was stolen or how many operators were hit.
The day in tech, in one email: TLDR is the daily newsletter with links and TLDRs of the most interesting stories in startups, tech and programming.
We may earn a commission if you sign up.
Co-founder Nicolas Dorier said the attackers logged in with administrator privileges on affected servers, and that the team had not yet worked out how the intruders obtained that access. He added that the project’s own public servers, which run 2.4.7, were not attacked.
Administrator logins on 2.4.1 and older
The first alert came late on Nov. 1 and asked operators to shut down their instances without giving technical details. According to crypto.news, the shutdown instruction was to run the project’s btcpay-down.sh script until the investigation finished, and hosting providers including LunaNode shut down some customer installations automatically, so affected operators may need to wait for a provider to restore service. Anyone who believes a server was compromised is asked to send incident details and logs to the project’s security contact.
Version 2.4.1 was released July 23, 2026. The Bitcoin Foundation’s write-up stresses that the clean record for 2.4.7 is the project’s own account as of Nov. 2, not an independent guarantee, and that neither the stolen total nor the number of affected operators has been disclosed.
Operators have three jobs, according to the coverage. They should update to 2.4.7, follow the project’s shutdown instructions if their instance was running an older version, and send logs to the security team if funds disappeared. The sequence of releases explains the urgency: 2.4.1 on July 23, the critical fix in 2.4.2 on Aug. 7, the incident post three days later, 2.4.7 on Oct. 29, and the first drain warning on Nov. 1, only three days after the newest release went out.
From the August Lightning flaw to release 2.4.2
The new warning comes less than three months after an earlier incident. BTCPay’s security incident post, published Aug. 10 and updated Nov. 2, says a vulnerability let an attacker obtain LND admin macaroon credentials from an instance and reach connected Lightning wallets, and that funds were stolen from some users. Updating to 2.4.2 also updates LND and regenerates the admin macaroon. The foundation gave 0.21 BTC each to Craig Raw and the Bitcoin Red Team fund for responsible disclosure, and supporters funded a recovery bounty of 10 percent of recovered funds, capped at 3 BTC.
The project’s release notes on GitHub record that 2.4.1 listed no security fixes, while 2.4.2 on Aug. 7 fixed a critical vulnerability described as being actively exploited and a TOTP two-factor bypass through Greenfield Basic authentication. Whether the August flaw connects to the administrator logins now being reported is unclear; Cointelegraph noted that BTCPay had not answered its request for comment and that the link was undetermined.
The reason administrator access matters is the hot wallet itself. A hot wallet keeps the signing keys on an internet-connected server, so anyone who can log in as an administrator can often move the funds without touching any cryptography. That is also why BTCPay’s earlier advice, repeated this week, is to keep only working balances on the server and the rest offline. Merchants who use BTCPay mainly to receive payments with a watch-only wallet are in a different position from those who also spend from the server.
The 2.4.2 notes carry more detail than a quick scan suggests. The developers recommended that integrators also update NBXplorer to version 2.6.10, and credited the Bitcoin Red Team effort, specifically the researchers brunoerg and benthecarman, for the issues reported. A breaking change in the same release disables Greenfield Basic authentication by default five minutes after account creation, with an opt-in available, which narrows one route that attackers have used against other self-hosted payment software.
Release 2.4.7 and the hot-wallet tradeoff
Release 2.4.7, dated Oct. 29, is described in the notes as a bug-fix release for security, reliability and payment-accounting issues, and updating is highly recommended, especially for servers shared by multiple merchants. It fixes 85 security findings from a scan by Anthropic’s OSS Scanner program: one critical, 13 high, 52 medium and 19 low. Examples include blocking cancelled payouts from being reopened and requiring authentication to read individual BitPay invoices.
Dorier’s advice for operators is blunt. A server-based hot wallet should hold only what its owner can afford to lose, because the team cannot guarantee that thefts like these will not happen again, and he runs 2.4.7 with a hot wallet himself. BTCPay’s incident post makes the same point, telling operators to keep funds in cold storage when possible and to move excess balances there regularly. The project has not yet said how the administrator access was obtained, so the full cause remains open.
This article was produced with the assistance of AI and reviewed by Morning Overview editors prior to publication.
The day in tech, in one email: Get TLDR →
We may earn a commission if you sign up.
More from Morning Overview
- Hybrids have 15% fewer problems than gas cars, while EVs and plug-in hybrids have about 80% more, Consumer Reports finds
- Regulators cleared the first U.S. small modular reactor, 4 months early
- Lake Powell sank to a record 3,517 feet, nearing the level that stops Glen Canyon Dam’s turbines
- Seven of Earth’s nine planetary boundaries are breached, and all seven are worsening
