BTCPay Server has linked reported hot-wallet drains to an attack vector affecting version 2.4.1 and older, narrowing an initial warning that asked operators to take their payment servers offline. The project is urging users to update and says it has received “no credible reports” of hot-wallet drains on its latest release, 2.4.7.
That is a more useful distinction than either “all BTCPay wallets are compromised” or “the problem is over.” Neither claim is supported by the official updates. For merchants, the immediate question is which software is running on their own instance—and whether the security work required by earlier advisories was actually completed.
What has BTCPay Server confirmed?
In its November 2 incident update, BTCPay said investigators had identified an attack vector targeting instances running 2.4.1, released in July, or an older version. It asked operators to update and directed affected users to send details and logs to security@btcpayserver.org.
The update followed an initial shutdown alert about unauthorized attackers sweeping hot wallets. A sweep means funds are moved out of a wallet; the warning was about reported thefts, not merely a service outage.
Founder Nicolas Dorier subsequently said the team had traces of vulnerabilities from before version 2.4.2 being used and would explain more in a later blog post. His earlier account said attackers had logged in as administrators on affected instances, while the team was still investigating how they obtained that access.
Does “no credible reports on 2.4.7” mean an all-clear?
No. It describes the reports BTCPay has received, not a guarantee that every installation is safe. Dorier said the project’s public servers, running 2.4.7, had not been attacked. The latest official statement is stronger on the version boundary than the first alert, but it does not close the investigation or certify individual merchants’ servers.
The official 2.4.7 release page is the place to verify the release itself. A version number in a news headline should not substitute for checking the software actually deployed, including a server managed by a hosting provider.
Why are hot wallets the focus?
BTCPay Server is self-hosted payment software, not a single exchange holding every merchant’s coins. Its wallet documentation distinguishes several ways to sign transactions, including hardware wallets, partially signed Bitcoin transactions and hot wallets.
With the hot-wallet option, a seed stored on the server can sign transactions automatically. That makes payouts convenient, but it also puts spending authority on an internet-connected machine. BTCPay explicitly warns that this feature has security implications. Receiving a payment and keeping the keys needed to spend it are separate jobs; a merchant does not have to treat them as the same thing.
How does the earlier 2.4.2 advisory fit in?
BTCPay’s earlier security advisory documented a flaw in releases before 2.4.2 that exposed LND credential files, known as macaroons. Those credentials can give an attacker control over a connected Lightning node. The advisory described an update and credential-regeneration process, not simply a change to a wallet’s display.
That history helps explain why old deployments matter. It does not, on its own, establish the complete chain of events behind every newly reported hot-wallet drain. The latest version findings and the older advisory should be read together without turning a partial explanation into a finished postmortem.
What should merchants verify next?
Start with BTCPay’s current official guidance and the release running on the actual server, rather than an older shutdown headline or a reply offering a private “fix.” Operators with affected instances should use the project’s published security contact and follow its update and remediation instructions. A hosting provider should be able to confirm what it has deployed and what security steps it has carried out.
The official updates reviewed for this article do not provide a total loss figure or a count of affected instances. They also do not announce a completed investigation. Until the promised technical explanation appears, those are gaps to acknowledge—not numbers or assurances to fill in.
