The affected line is version 2.4.1 and earlier. Recovery means a fresh host and wallet, plus replacement of potentially exposed secrets the old server could access.
BTCPay says attackers stole Bitcoin and Litecoin from hot wallets on servers running version 2.4.1 or earlier. Its November 2 advisory says the attackers used a different method to exploit the vulnerability fixed in 2.4.2 on August 7.
The project’s timeline begins with a reported wallet drain at 13:46 UTC on November 1. BTCPay received its first theft report by email at 20:56. During November 1 it contacted hosting providers, and at 22:25 it warned operators to shut down while it investigated. The next day it identified the affected version boundary.
BTCPay says it has seen no impact from these attacks on servers that were already running 2.4.2 or later when the warning went out. It has not established when exploitation began.
That produces two different operational states. A server running old code needs the fix. A server that may already have been entered needs its trust rebuilt, including each potentially exposed credential.
The August release contained the fix. The November response has to account for access already gained on the machine and the secrets that server could reach.
BTCPay defines the affected hot wallets as wallets whose spending keys were held on the server; its investigation tied the theft reports to version 2.4.1 and earlier.
The same vulnerability arrived by another method
BTCPay released version 2.4.2 on August 7 to fix a vulnerability that had been under active exploitation. The project’s current advisory now connects the November theft reports to that same vulnerability, exploited through a different method on servers that remained at 2.4.1 or earlier.
The public advisory does not name a CVE, publish the new exploitation path or attribute an actor. It does establish a usable boundary for response: which versions were in the affected set, when the project received its first reports and what operators of those systems should do next.
That boundary is broader than a check for a missing update. BTCPay recommends that every operator of a 2.4.1-or-older server move to a fresh machine with a new wallet, even when no theft has been noticed and even when the old machine was updated after the November 1 warning.
The project also accepts a share of the communication failure. It says it wishes it had done more after the August advisory to reach users who were still running older versions. That matters in a self-hosted fleet: a release can be available centrally while the exposed copies remain distributed across systems the project does not control.
BTCPay says updating alone cannot remove access an attacker may already have gained; operators of 2.4.1 and earlier are being told to provision a fresh server rather than restore the old machine wholesale.
The server held the authority to spend
A hot wallet keeps the keys needed to spend funds on the server itself. That arrangement supports fast, automated payment operations, but it also places application control and transaction authority inside the same failure domain.
Once an intruder gains enough control of the server, the path to the wallet is short. The application is already designed to use the signing material without a separate offline ceremony. A server-held spending key turns administrative compromise into a custody event.
BTCPay says wallets whose spending keys were held off the server, including hardware wallets, were unaffected by these thefts. The distinction is architectural, not cosmetic. An online service that can observe payments but cannot sign them denies a server intruder the final transaction authority.
Off-server keys do not make an old application server safe. BTCPay still recommends rebuilding affected-version servers because the host may contain other secrets or provide a path to connected services. Key placement limits one consequence; it does not restore trust to the machine.
BTCPay says the reported thefts did not affect wallets whose spending keys were kept off-server; keeping the signer outside the application host separates server access from spending authority.
Four states define the incident
The available evidence becomes clearer when the response is divided into four states:
Exposure: The server was running 2.4.1 or earlier during the relevant period. That places it inside the version range BTCPay identified.
Access: An intruder gained control of the application or host. Administrator records, host logs, account changes and other forensic evidence establish this state.
Authority: Spending keys or other high-impact secrets were available to the compromised server. Wallet configuration and the server’s connected credentials define that reach.
Impact: An unauthorized transaction or another confirmed action occurred. Wallet history, application events and business records establish what moved and when.
Version inventory identifies exposure; it cannot reconstruct the remaining three states by itself. An unchanged wallet balance does not rule out earlier access. BTCPay therefore tells operators of affected versions to rebuild even when they have not observed a theft.
The project published destination addresses reported in incidents, while warning that some activity at those addresses predates the theft reports. It has not established the full transaction timeline or which transfers belong to this incident. Address balances are therefore unsuitable as a confirmed aggregate loss figure.
This is why the response needs both records: wallet history shows financial impact, while server and application evidence show how far access traveled.
Recovery starts from a clean host
Installing a fixed release is prevention for a server that remains trustworthy. BTCPay’s recovery guidance treats suspected prior access as a separate problem because an update cannot remove an account, copied key or persistence mechanism created before the patch.
For operators of 2.4.1 or earlier, the project’s sequence is concrete:
New wallet: Create it from a trusted device with a new seed, then sweep any remaining hot-wallet funds into it.
Old host: Take the server offline and preserve relevant logs and transaction records.
Clean server: Provision a fresh virtual machine, install the latest supported BTCPay Server from trusted sources and avoid restoring the old machine wholesale.
Reachable credentials: From a trusted device, revoke and replace credentials the old server could access, including hosting, SSH, application, API and Lightning credentials.
Logs can contain secrets. BTCPay tells affected users to remove credentials before sharing material and never send seed phrases, private keys or passwords. Preserve the original evidence privately; provide only the scoped, sanitized material needed for external investigation.
BTCPay’s recovery sequence is to preserve evidence, create a new wallet, provision a clean server without restoring the old host wholesale, and replace potentially exposed credentials the old host could access from a trusted device.
Patch reach is part of custody
The hardest control in this incident is not writing the patch. It is knowing whether every exposed self-hosted instance received it before an attacker arrived.
An operator accepting money through an internet-facing server needs a current inventory of deployed versions, an alerting path that distinguishes security releases from ordinary maintenance and confirmation that the update actually completed. The project needs a way to make urgent notices difficult to miss without taking ownership away from the person running the server.
Wallet design belongs in that same control set. If daily operations require a hot wallet, bound its balance to the amount the service genuinely needs, monitor withdrawals against business events and keep long-term funds behind a signer outside the application host. Prepare the clean-rebuild and secret-rotation procedure before a public warning turns it into an emergency.
For self-hosted payment infrastructure, patch delivery, key placement and clean-host recovery are one control surface. A security release protects only the instances it reaches; a rebuilt machine and a new wallet address the access that may already exist.