Updated November 3, 2026.
BTCPay Server has identified version 2.4.1 and earlier as the targets of hot-wallet thefts reported on November 1. In its November 2 notice, the project recommends a fresh machine and a new wallet for operators of those installations, including people who have since updated their software.
The important distinction is that closing a vulnerability does not automatically remove access an attacker may already have obtained. An unchanged balance does not rule out an earlier compromise. The response therefore depends on the version running when the warning was issued, not just the version displayed today.
BTCPay Server: which installations are affected
The official November 2 notice identifies servers running 2.4.1, released July 23, or earlier. According to the team, attackers used a different method to exploit a vulnerability fixed in 2.4.2 on August 7. This is not described as a flaw in Bitcoin’s underlying protocol.
For servers already running 2.4.2 or later when the November 1 warning was issued, the project says it has seen no impact from these attacks. That is a bounded finding from this investigation, not a guarantee that any installation is immune to unrelated vulnerabilities or future attacks.
| Situation | Project guidance |
|---|---|
| 2.4.2 or later before the warning | No observed impact from these attacks |
| 2.4.1 or earlier | Fresh server and new wallet, even without visible theft |
| Updated from an old version after the warning | The rebuild recommendation still applies |
| Theft or unauthorized access | Treat the machine and accessible secrets as compromised |
Why patching is not the same as cleaning a machine
An update fixes the code distributed by the project. It does not establish that a stolen password has become unusable, an unauthorized session has ended or every component of the old machine remains trustworthy. Treating prevention and recovery as identical can leave an already acquired access path in place.
That is why the recommendation is not to restore the entire old server onto a replacement machine. The team calls for a fresh environment with supported software and replacement credentials. This does not mean indiscriminately erasing evidence: relevant logs and transaction records should be preserved before replacing the old environment.
Hot wallets versus spending keys held elsewhere
A hot wallet stores the keys needed to spend on the server. In the incident described, compromising the machine can consequently have direct consequences for funds. Our explanation of custodial and non-custodial wallets separates key control, connectivity and the responsibilities involved in operating a wallet.
The project says these thefts did not affect funds whose spending keys were held off the server, including hardware wallets. That does not establish that an old installation is trustworthy simply because it uses an external signing device. The recommendation to rebuild an outdated server still applies when its spending keys are stored elsewhere.
A new wallet needs a new secret
The official sequence starts with creating a wallet on a trusted device using a new seed, then sweeping remaining hot-wallet funds into it. Reusing the old seed on the new machine leaves those funds at risk if the secret was exposed. A new receiving address and an independently generated new secret are not automatically equivalent.
Our explanation of seed phrases and their protection develops that distinction. Do not paste an old seed into a recovery website or send it to someone offering assistance. The incident notice explicitly says not to share seed phrases, private keys, passwords or other credentials with the security team either.
After protecting remaining funds and preserving evidence, the project says to take the old server offline and provision a clean virtual machine. Potentially exposed credentials should be revoked and replaced from a trusted device. Entering their replacements on the suspect machine would undermine the separation the rebuild is intended to establish.
Release 2.4.7 does not rewrite the exposure history
Preserving a copy for an investigation is different from putting it back into production. Necessary recovery materials should be retained before replacing an environment, without losing the only available copy. That precaution does not make potentially exposed credentials or seeds safe to reuse.
The official 2.4.7 release notes, dated October 29, describe further security, reliability and payment-accounting fixes. They help identify the available update, but their existence does not show that a machine left vulnerable until November was never accessed beforehand.
A software release and an incident-response notice answer different questions: which code to install, and how to handle an environment already considered suspect. Operators using a hosting provider are directed to seek help moving to a fresh VM. CryptoRoad has not performed upgrades, transferred funds or tested any reader’s installation as part of this report.
Loss totals cannot be inferred from the destination addresses
BTCPay Server lists addresses reported in the incidents, but warns that some activity may predate the thefts it knows about. Their balances and transaction histories therefore do not constitute a confirmed total of losses. We do not attribute every transfer to this incident or suggest that published addresses establish a guaranteed recovery path.
A useful report includes the previous version, times with the applicable time zone and public transaction references, with secrets removed from logs. Where funds were stolen, the project also recommends reporting the theft to local authorities. The practical message is to establish historical exposure and rebuild trust in the environment, rather than stop after seeing an updated version number.
