BTCPay Server Pins Hot Wallet Thefts on Outdated Software

BTCPay Server has identified an attack vector draining funds from hot wallets on outdated installations of its Bitcoin payment software, and it's urging every operator still running version 2.4.1 or earlier to update immediately.

The open-source payment platform disclosed the findings on Monday, closing an investigation that began with reports of unauthorized withdrawals from users' hot wallets. The vulnerable range covers every release up to and including version 2.4.1, which shipped on July 23, 2026, according to the project's statement.

Operators running the current release, version 2.4.7, appear safe. BTCPay said it has received no credible reports of hot wallet drains among users on the latest version, and it directed all operators to upgrade their installations as the primary remediation step.

What happened before the disclosure?

The version-specific findings followed an earlier, more urgent warning. Before it had isolated the attack vector, BTCPay told operators to shut down their server instances entirely while it investigated the unauthorized wallet withdrawals. The project also published step-by-step instructions for taking servers offline safely.

That guidance has now shifted from shutdown to patching. The distinction matters operationally: a full shutdown takes a merchant's Bitcoin payment acceptance offline, while an update preserves service. Merchants and hosting providers that heeded the original warning can now restore operations on patched software rather than remaining dark.

BTCPay has not disclosed the scope of the damage. The project has confirmed neither the number of affected operators nor the value of stolen funds. It also hasn't published the technical mechanism attackers used to reach the hot wallets. Affected users are being asked to submit information and logs to BTCPay's security team, which suggests the internal picture is still incomplete and the incident response is ongoing.

Cointelegraph says it reached out to BTCPay Server for comment and did not receive a response before publication.

Is this connected to August's Lightning incident?

The timeline raises an obvious question. Less than three months ago, BTCPay restricted remote Lightning access after an August attack exploited a vulnerability to obtain credentials for the Lightning Network Daemon, or LND, and steal funds through that channel.

It remains unclear whether the newly identified hot wallet attack vector is connected to the August vulnerability. The two incidents differ in target — LND credentials versus direct hot wallet access — but BTCPay has not ruled out a relationship, and the absence of technical detail leaves the question open.

The back-to-back disclosures put the project in an uncomfortable position. BTCPay is widely used by merchants who self-host Bitcoin payments precisely to avoid third-party custody, and hot wallets by design hold keys on internet-connected servers. Two distinct attack campaigns within a quarter, both ending in stolen funds, test the operational assumptions behind that self-hosted model — even when the immediate fix is as simple as running current software.

What should operators do now?

For anyone operating a BTCPay instance, the actionable picture is narrow and clear:

• Update to version 2.4.7, the latest release, which has shown no credible reports of hot wallet drains.
• Check the version history. Any instance at version 2.4.1 or earlier — anything released on or before July 23, 2026 — falls inside the vulnerable range.
• Preserve logs if funds have already moved without authorization, and submit them to BTCPay's security team rather than wiping or rebuilding the server first.

The mechanics of the compromise remain undisclosed, so operators shouldn't assume that patching alone retroactively secures a wallet that was already exposed. Until BTCPay publishes technical detail on how attackers accessed the hot wallets, affected operators have little basis to assess whether keys, server credentials or something else were the entry point.

The open questions — stolen value, victim count, attack mechanism, and any link to the August LND incident — now sit with BTCPay's security team. Operators running outdated instances shouldn't wait for those answers: the vulnerable version range is public, the safe version is public, and the update path is the one control every operator holds today.