The official BTCPay Server account urged operators to shut down their instances on November 1, saying hot wallets were being swept by unauthorized attackers. It instructed users to run ./btcpay-down.sh and keep their servers offline until the investigation was complete.
The project did not disclose how much bitcoin had been stolen, how many deployments were affected, or whether a confirmed remedy was available. The warning applied broadly to operators rather than only to a named group of installations, putting merchants in the position of suspending payment operations without a clear estimate of the exposure.
CoinDesk reported on the shutdown warning and quoted BTCPay founder Nicolas Dorier as saying the reported thefts appeared to involve releases older than version 2.4.2. Dorier did not confirm that newer versions were safe, and the project had not identified the attack vector. He said attackers had obtained administrator level access, but the team had not established how those credentials or permissions were acquired.
Dorier also said BTCPay’s own public servers, which were running version 2.4.7, had not been attacked. That distinction may help narrow the investigation, but it does not yet establish that all installations running newer releases are protected. For merchants, version status is therefore only one part of the immediate capital preservation problem. The other is whether an online wallet remains exposed while the instance is running.
An earlier credential theft
The new warning follows a separate August security incident involving older BTCPay releases. In its August 7 security advisory, BTCPay warned that versions before 2.4.2 contained a critical vulnerability that could allow remote attackers to obtain credential files associated with LND, the software used to operate Lightning nodes.
That advisory said attackers could use the credentials to move funds from connected Lightning wallets. It also said on chain BTCPay hot wallets were not affected by that earlier vulnerability. The distinction matters because the November reports specifically concern hot wallets, suggesting either that unpatched installations remain exposed to consequences of the earlier weakness or that attackers found another path into administrator controlled systems.
In a later incident response update, BTCPay confirmed that the August vulnerability had been exploited to steal funds from connected LND wallets. The project said remediation included updating to version 2.4.2 and regenerating credentials.
The available information does not establish whether the latest wallet drains are connected to that earlier flaw. It also does not show whether the attackers reached wallets through stolen credentials, a separate software vulnerability, or compromised administrator accounts.
Self custody under operational stress
BTCPay’s model gives merchants control over their payment infrastructure rather than routing funds through a centralized custodian. That design can reduce reliance on an intermediary, but it also places patching, credential management and incident response closer to the businesses holding the funds.
A hot wallet is especially important in this context because it is intended to remain available for transactions. If its signing capability is exposed through a compromised server, the balance can become immediately transferable. Shutting down the instance interrupts that flow, but it also interrupts payment processing and may leave merchants unable to determine whether their remaining funds are secure.
NodeWitness analyzed the incident’s on chain activity and criticized the operational exposure of self hosted hot wallets, noting that independently operated deployments could remain online after the warning. That is the only critical outside assessment identified in the available materials. No opposing response from affected merchants or another independent security team was provided.
The next decisive facts are the number of affected deployments, the attack path, the versions involved and whether stolen funds can be recovered. Until those questions are answered, BTCPay operators must balance the cost of taking payment systems offline against the possibility that keeping an internet connected hot wallet active could allow further capital to leave.
- bitquery.io · Link preview (og:image)
Ethan Brooks is not a person. No notebook, no deadlines, no face behind the name — just a byline this newsroom publishes under. Here is the production line underneath it, because a name beside a portrait reads like a journalist, and this one is not one.
The models. Writing: gpt-5.6-luna. Out on the live web: gpt-5.6-luna and gpt-5.6-terra. Pictures: gpt-image-1. Swap one in the newsroom and this line swaps with it — it is read off the machines, not typed here.
How a story is made
- Research. The searching model reads around the story, pointed at primary sources — the filing, the post, the repository — rather than at somebody else's write-up of them.
- Writing. The writing model drafts it against what was found, at Ethan Brooks's usual length and in Ethan Brooks's usual register.
- The loop. A reviewer reads the draft and sends it back with notes. Then reads it again. A piece can go round several times before it leaves the building.
- Enrichment. A quotation has to appear word for word on the page it is taken from. A chart may only use figures that appear in the source it cites. Whatever fails is dropped, and the reason is kept.
- Fact check. A last pass hunts for claims the article makes and its sources do not.
- A human stop. Sensitive subjects are held for a person to read before publication, and a person can kill any of it at any point.
If that sounds less like a newsroom and more like a factory: quite. It is called Press Factory.
This article was generated using AI and published automatically without human pre-publication review.
Read and checked by admin on 11/2/2026
How this article was made
The article was produced by the Grandmonts Media News Engine using automated research, drafting and verification workflows. No human editor reviewed the article before publication. Grandmonts Media remains responsible for the published content. Errors can be reported at office@grandmonts.cz.