- BTCPay Server says thefts from hot wallets hit servers running version 2.4.1 or earlier. The project says it has seen no impact on servers running 2.4.2 or later.
- The project says updating cannot remove access an attacker may already have gained. It advises a fresh server with a new wallet and seed.
- Ask which payment servers keep spending keys on the machine, and which version each one runs.
A patch protects the future, not the past
Installing a security update closes a hole. It does not show whether someone has already come through it. That is the practical lesson of the BTCPay Server thefts.
BTCPay Server is open-source software that businesses run to take cryptocurrency payments. On 1 November 2026, the project began receiving reports of Bitcoin and Litecoin stolen from hot wallets. In a hot wallet, the spending keys sit on the same server that runs the software.
What the project and the analysts report
The project's investigation tied the thefts to servers running version 2.4.1 or older. Version 2.4.1 was released on 23 July 2026. Version 2.4.2 followed on 7 August and fixed a vulnerability. The project says the attackers used a different method against that vulnerability.
Servers already on 2.4.2 or later when the project warned the community on 1 November showed no sign of these attacks, it says.
Infosecurity Magazine reports that Bitquery, a blockchain analytics firm, followed 18.38 Bitcoin and 3,405 Litecoin to two addresses BTCPay Server named. The magazine puts the value at about $1.63m. The coins moved in 682 sweeps between 30 October and the morning of 2 November.
These totals need care. BTCPay Server says some activity at those addresses seems to predate the thefts in its reports. It has not published a loss total. It says the balances are not a confirmed count of losses.
Bitquery treats its figure as a minimum. The count covers only the two named addresses and two coins. Anything held elsewhere, Lightning balances included, sits outside it. Bitquery also cannot say how many servers were hit, because a blockchain records wallets, not machines.
How a hot wallet works, and why administrator access matters
A hot wallet trades safety for convenience. The keys that authorise spending are stored on the server itself, so the software can pay out without a person approving each move. The cost is plain. Whoever controls that server can reach the keys.
Bitquery's analysis says the person behind the thefts used administrator logins on the affected servers. It says the funds were then moved out of the hot wallets. An administrator account is the one that manages a server's settings, and the wallets are among them. The sources do not say how the attacker obtained that access. The project's post does not describe the flaw, and this article does not guess.
The project says funds whose signing keys sit elsewhere, such as on a hardware device, were not touched by these thefts. It still recommends rebuilding an older server even when keys are kept off it.
Here is why a late update falls short. The project's recovery guidance says an update cannot remove access an intruder may already have gained. A patch repairs the software. It does not evict anyone who got in first. The recovery list shows how much a server can hold. It asks operators to replace hosting, SSH, application, API and Lightning credentials.
The project says users can check their version by logging in and reading the bottom of the page. It announces releases on X and in a Telegram chat. It also says it wishes it had done more to reach users still on older versions. An operator has to install each update, so an older server stays exposed until someone does.
Two statements, three months apart
Infosecurity reports that the vulnerability 2.4.2 fixed had already been used in August to take funds through LND, software for the Lightning Network. At that time the project said its on-chain wallets, hot wallets among them, were not affected.
In November, on-chain hot wallets on older servers were emptied. The sources do not say the August statement was wrong when it was made. They do not link it to any delay in updating.
The point is a general one. A statement about scope describes a moment. It is not a promise about the next attacker's method. Leaders should treat such statements as a snapshot and ask what has changed since.
The timeline, and what it leaves open
The project's timeline lists three events on 1 November. A wallet drain described in incident reports is dated 13:46. The first theft email arrived at 20:56. A warning asking operators to shut down went out on X at 22:25. The project gives no time zone for the first two. Infosecurity gives UTC only for the 22:25 warning.
Bitquery's sweeps begin on 30 October, before the 13:46 drain. The project says some activity at these addresses may predate the thefts, so the 30 October sweeps may not all be attacks. It also says it has not established when attackers first began exploiting the vulnerability.
Bitquery says 87% of the traced funds moved in one wave on the afternoon and evening of 1 November. It counted 267 more sweeps, worth about $150,000, after the shutdown request.
Why updating now may not be enough
The project's guidance says a balance that looks unchanged does not show that nobody got in earlier. Anyone still on 2.4.1 or older should set up a clean machine and a newly created wallet, it advises, and move leftover funds first. That holds even without a noticed theft. It also holds for operators who updated after the 1 November warning.
Its steps run as follows. Create the new wallet on a trusted device with a new seed. Take the old server offline and keep its logs. Build a fresh virtual machine rather than restoring the old one. Replace credentials from a trusted device.
Questions to put to your team
Start with inventory. Which payment servers do we run, and which version is each on? Who reads release notices, and where do they appear?
Then ask about exposure. Do any servers hold spending keys on the machine? If so, how much value sits there beyond daily needs? The project advises keeping only operating funds on the server.
Finally, ask about recovery. If a server were compromised tonight, could we rebuild it from scratch and replace every credential it touched? A patch is the cheap part. The rebuild plan decides what a compromise costs.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: BTCPay Server.
