BTCPay Server Tells Operators to Rebuild as $1.63M Is Traced

BTCPay Server has told anyone who ran version 2.4.1 or earlier to move to a new server with a new wallet, even if they have since updated and noticed nothing missing. Hot wallets on self-hosted instances were swept between 30 October and the morning of 2 November. Bitquery, a blockchain analytics firm, traced about $1.63 million of bitcoin and litecoin to two addresses the project named. That is a floor and not a loss total. BTCPay has published no total, and how the attacker obtained administrator access is still blank.

What the traced figure covers

The composition is the part every account agrees on: 18.38 BTC and 3,405 LTC. CryptoSlate, Infosecurity Magazine, TokenPost and The Cryptonomist all print those two numbers. TokenPost gives the sum as $1,628,450, priced off Monday morning rates, but attributes the work only to "an on-chain estimate" and names nobody; the other three credit Bitquery. The number is not in dispute. Who produced it is reported differently.

Bitquery's caveats do more to limit it than any rival count. It covers the two named addresses only, so other coins and addresses sit outside it, Lightning funds among them. Some activity at those addresses looks older than the thefts.

682 sweeps, and the ones after the warning

Bitquery counted 682 sweeps across the window, with 87% of the traced value moving in one wave on 1 November. CryptoSlate places that wave in an eight-hour window; Infosecurity and The Cryptonomist put it in the afternoon and evening. The two do not reconcile and both stand.

The warning did not stop the sweeping. BTCPay asked operators at 22:25 UTC on 1 November to shut their instances down, and Bitquery logged 267 more sweeps worth about $150,000 after that. Where the count ends is unsettled too. CryptoSlate and Infosecurity say Bitquery stopped at 06:00 UTC on 2 November, while TokenPost splits it, with bitcoin counted to 05:42 and litecoin to 06:00. We could not establish which cutoff the $1.63 million uses. Bitquery is explicit that 682 sweeps is not 682 merchants, since one wallet can be emptied in several transactions

Why updating was never the fix

The flaw itself was patched on 7 August in version 2.4.2. What ran last week used a different method against the same flaw, and no account read here describes that method. Core Lightning likewise held the details of AI-found bugs for 14 days in its own disclosure. Parameter.io reports co-founder Nicolas Dorier confirming that intruders held administrator-level credentials. Infosecurity, reading Bitquery, says the thief signed in as an administrator and swept the wallets. Neither establishes how that access was reached.

"Updating alone cannot remove access an attacker may already have gained," BTCPay said.

So the advisory asks for a rebuild. Operators are told to generate a new seed on a trusted device, retire the old machine with its logs kept, install fresh instead of restoring the old system, and replace hosting passwords, SSH credentials, API keys and Lightning credentials. Wallets whose spending keys live off the server were untouched; a hot wallet keeps those keys on the machine so payments clear without a person present. Hosting providers were asked to pull affected instances offline, LunaNode named among them.

The count of servers is still missing

Two claims about the current release circulate, and they are not the same claim. TokenPost reads the 1 November warning as clearing servers on 2.4.2 or later. Parameter.io and GN Crypto quote the next day's line as no credible reports of drains for users on 2.4.7, dated to 29 October by CryptoSlate alone.

August's episode sits beside this one without being joined to it. That flaw let an unauthenticated remote attacker obtain LND credential files, LND being one implementation of the Lightning payment layer. It pushed the project to restrict remote access to Lightning services, and another implementation has since blocked every browser request to its node API. BTCPay said on-chain wallets were unaffected in August. Three accounts say nobody has established whether the two episodes are connected. What would settle the scale is a server count, and no one has one.