Summary
- Thefts affected hot wallets on BTCPay Server 2.4.1 and earlier.
- The underlying weakness was patched in version 2.4.2 in August.
- Potentially compromised operators are advised to rebuild servers and create new wallets.
Operators of outdated BTCPay Server installations have been told to rebuild compromised systems and create new cryptocurrency wallets after attackers exploited a previously patched weakness to steal funds.
The open-source payment platform BTCPay Server confirmed thefts from hot wallets on systems running version 2.4.1 or earlier. The underlying weakness was corrected in version 2.4.2, released on 7 August.
Reports of unauthorised transactions began reaching the project on 1 November. Its investigation indicated that attackers were using a different route to exploit the same underlying weakness, even though an earlier software update had addressed it.
The project contacted hosting providers and urged operators of affected legacy installations to take them out of service. It has not published a verified total for the funds stolen across all victims.
A hot wallet keeps the cryptographic material needed to authorise transactions on an online system. That arrangement can simplify payment processing, but it exposes funds when an attacker gains sufficient access to the server or its signing environment.
Cryptocurrency transactions can move assets rapidly between addresses without a conventional central payment operator able to reverse the transfer. Their traceability does not guarantee the recovery of funds once an unauthorised transaction has been confirmed.
BTCPay Server identified a wallet-draining transaction on 1 November and received the first related theft report that evening. The project has not established when the earliest unauthorised access began, and it is investigating other suspicious activity potentially associated with the incident.
The amount held at addresses linked to an investigation should not be treated as a confirmed loss figure. Such balances can include unrelated funds, multiple transfers, and transactions that cannot yet be tied to a particular victim.
The project’s recovery guidance distinguishes applying a patch from restoring trust after a compromise. An updated application can close the original vulnerability while leaving behind altered system components, compromised credentials, or secrets copied before remediation.
Operators of affected systems have therefore been advised to provision a fresh server instead of relying on an in-place update. The guidance also calls for creation of a new wallet with a newly generated recovery seed.
Reusing an existing recovery seed would be unsafe if an attacker had obtained it during the intrusion. Moving funds to a wallet created from new cryptographic material reduces the risk that previously exposed secrets remain usable.
Credentials for hosting platforms, SSH access, APIs, and other connected services may also require replacement, depending on what the compromised environment could access.
These steps reflect the unusual overlap between software security and direct financial custody in self-hosted cryptocurrency payments. A server may process transactions and also hold the authority to move assets, connecting technical intrusion to immediate monetary exposure.
Wallets whose spending keys remained outside the affected servers, including appropriately configured hardware wallets, were not implicated in the reported hot-wallet thefts. That separation changes what an attacker can do after compromising the payment application.
Organisations using a self-hosted payment service retain control over their deployment but must manage application updates, server access, security monitoring, and recovery arrangements themselves. Those duties can be divided among businesses, contractors, and hosting providers.
The incident shows how an August security fix can leave continuing exposure where operators have not deployed it. Availability of a correction is only one part of the process; the affected server must actually be identified and updated.
BTCPay Server said installations that were already running version 2.4.2 or later had not shown evidence of compromise through this specific campaign. That is not a guarantee against other weaknesses or unrelated attacks.
The project continues collecting incident evidence and investigating the reach of the activity. Its current advice treats legacy systems suspected of compromise as environments requiring reconstruction and replacement of wallet secrets, not simply routine patching.
