BTCPay Server Links Hot Wallet Thefts to Instances Running Version 2.4.1 or Earlier

BTCPay Server has traced a series of unauthorised withdrawals from merchants' hot wallets to an attack vector affecting older versions of its software, and is urging operators to upgrade to the latest release.

The open-source Bitcoin payment platform said on Monday that its investigation had identified a weakness in instances running version 2.4.1 or earlier, according to Cointelegraph. The project said it had received no credible reports of wallets being drained among users on version 2.4.7, its most recent release.

From shutdown order to upgrade advice

The update followed an earlier and more drastic warning. When reports of funds disappearing first reached the project, BTCPay asked operators to shut down their server instances altogether while it looked into the withdrawals, and published instructions explaining how to do so.

That sequence matters. A shutdown request is the bluntest tool available to the maintainers of self-hosted software, because they cannot switch off users' installations themselves. Asking merchants to take their payment infrastructure offline means asking them to stop accepting payments, at least temporarily, which signals that the project regarded the risk of continued losses as more serious than the disruption.

The later guidance narrows the problem. By identifying the affected range as version 2.4.1 and earlier, BTCPay has effectively told operators that the most direct remedy is to move to 2.4.7. Version 2.4.1, according to the report, was released on 23 July.

What has not been disclosed

Significant gaps remain in the public picture. BTCPay has not said how many operators were affected, how much was stolen or how the attackers gained access to the wallets. It has asked anyone who lost funds to send information and logs to its security team.

Cointelegraph said it contacted BTCPay Server for comment but had not received a reply by the time of publication.

Withholding technical details during an active incident is common practice in software security. Publishing the precise mechanics of an exploit before most users have patched can hand a blueprint to other attackers. The trade-off is that operators are left to act on trust: they are told to upgrade without being able to assess for themselves whether their own systems were exposed or compromised.

The request for logs also suggests the investigation is still gathering evidence. Server logs from affected installations would typically help maintainers reconstruct how an intrusion unfolded, confirm the scope of the vulnerable versions and determine whether any further fixes are needed.

Why hot wallets are the weak point

BTCPay Server occupies a particular niche in the Bitcoin ecosystem. Rather than relying on a third-party processor that holds funds on their behalf, merchants run the software themselves, receiving payments directly into wallets they control. That model removes the custodial risk of handing money to an intermediary, but it shifts responsibility for security onto the operator.

A hot wallet is one whose keys are held on an internet-connected machine, allowing it to send funds automatically. That convenience is useful for features such as refunds, payouts or Lightning payments, which require the server to sign transactions without manual intervention. It also means that anyone who gains sufficient control of the server may be able to move the money.

Merchants who receive payments into watch-only wallets, where the signing keys are kept elsewhere, are generally less exposed to this kind of theft, since the server cannot spend funds on its own. The incident is likely to renew attention on how much value operators keep in hot wallets at any given moment, and on how quickly they sweep receipts into colder storage.

A second incident in quick succession

The latest reports arrive less than three months after a separate security problem. In August, an attacker exploited a vulnerability to obtain credentials for the Lightning Network Daemon, or LND, and used them to steal funds. BTCPay responded by restricting remote Lightning access.

LND is one of the most widely used implementations of the Lightning Network, Bitcoin's layer for fast, low-cost payments. Credentials for an LND node can grant the ability to make payments from it, which is why their exposure is so sensitive.

It is not yet clear whether the newly identified attack vector is related to the August vulnerability. If the two are connected, it would raise questions about whether the earlier remediation fully closed off the avenue of attack. If they are unrelated, it would point to two distinct weaknesses surfacing within a short period, which could weigh on confidence among merchants who rely on the software.

Either way, the back-to-back incidents underline a broader tension in self-hosted financial software. Open-source projects of this kind are often maintained by small teams and depend on operators to apply updates promptly. Installations that are left running older versions for months can become attractive targets once a flaw is identified.

Risks and open questions

There are reasons for caution in reading too much into the limited information released so far. The absence of credible reports among version 2.4.7 users is encouraging, but it is not the same as a confirmation that the latest release is immune. Reports could still emerge, and the investigation is ongoing.

The scale of the incident is also unknown. Without figures on the number of affected operators or the value lost, it is impossible to judge whether this was a handful of isolated drains or a wider campaign. Self-hosted deployments are, by nature, difficult for any central team to count or monitor.

Operators who upgrade should also bear in mind that patching a vulnerable server does not necessarily undo a compromise that has already occurred. If an attacker obtained keys or credentials before the update, those may remain usable. Security practitioners typically advise rotating credentials and moving funds to fresh wallets after a suspected breach, though BTCPay's own published guidance should take precedence for its users.

What to watch next

The coming days are likely to determine how serious the episode proves to be. Key points to follow include:

• Whether BTCPay publishes a technical post-mortem explaining how the attack worked
• Any disclosure of the number of affected operators and the total value stolen
• Confirmation of whether the attack is linked to the August LND vulnerability
• Further guidance for operators who may already have been compromised

For now, the project's message to merchants is straightforward: those running 2.4.1 or earlier should treat their installations as at risk, and those who have suffered losses should share their logs with the security team. How transparently BTCPay accounts for the incident once its investigation concludes may matter as much to its users as the fix itself.