BTCPay Server Drains Reach $1.63M, Bitquery Finds

BTCPay narrows wallet-drain warning to older versions

In its November 2 incident update, the project identified an attack vector targeting version 2.4.1, released July 23, or older. It said there were no credible reports of hot-wallet drains among users running the latest 2.4.7 release and urged operators to keep their software updated.

That is more specific than the initial November 1 alert, issued at 22:25 UTC. The earlier message asked anyone operating an instance to shut it down with ./btcpay-down.sh while the investigation continued.

Founder Nicolas Dorier said attackers gained administrator access on affected installations. His initial account did not explain how that access was obtained. He subsequently reported traces of vulnerabilities predating 2.4.2, with further detail promised in a blog post.

The version distinction helps operators assess their exposure, but it does not substitute for a complete technical account. Absence of credible reports on a release is narrower than a guarantee that every deployment is secure, particularly where operators have customized their installations.

BTCPay also thanked hosting providers, including LunaNode, for shutting down instances to protect older installations. A merchant’s unavailable checkout may therefore reflect a precaution taken by its host rather than evidence that its own wallet was emptied.

Bitquery traces losses across Bitcoin and Litecoin

The dedicated loss-impact check for this article, completed at 11:08 UTC November 2, found Bitquery’s on-chain investigation estimating 18.38 BTC and 3,405 LTC stolen in 682 sweeps. The valuation uses November 2 prices and a 06:00 UTC cutoff.

Bitquery counted 267 sweeps worth about $150,000 after the alert. Most tracked funds remained parked at its cutoff, which does not establish recovery.

The firm could not determine a server count; its totals exclude Lightning. Transactions are not individual victims. Daily Crypto Briefs has not independently reproduced the calculation. The reviewed primary project updates did not provide a final loss total or reimbursement plan.

This is a separate operational exposure from the recent Binance withdrawal disruption. An exchange holds customer assets centrally; a self-hosted merchant controls its own installation and the decision to place spending keys on that machine.

BTCPay hot-wallet keys change the merchant risk

The project’s user guide distinguishes a hot wallet, which retains its private key on the server, from a watch-only wallet, which requires an external signer. The former allows convenient spending from the interface but exposes funds if the server or account is compromised.

Direct settlement, a feature also highlighted in Bitcoin merchant payment services, describes who receives funds. It does not establish where the recipient stores its keys or how securely its server is maintained. Those are separate operational choices.

The earlier August security advisory addressed stolen credentials for LND, a Lightning Network implementation. It expressly distinguished that credential risk from BTCPay’s own on-chain hot wallets. The November reports should not be described as the same fully established mechanism without a technical postmortem connecting them.

Operators can compare their installed version with the official 2.4.7 release record. Dorier’s latest guidance emphasized frequent updates and limiting hot-wallet balances. The project asked affected users to send details and logs to its security team.

Alternative.me’s Bitcoin Fear & Greed Index read 37, or Fear, on November 2, compared with 34 previously. It measures broad market sentiment rather than merchant losses or the safety of BTCPay deployments.

The next substantive disclosures are the promised technical explanation, a verified affected-server count and any recovery or compensation arrangements. Until those appear, the version-specific project guidance and the timestamped analytics estimate answer different questions about exposure and measured losses.