BTCPay Server, the free self-hosted bitcoin payment software, asked everyone running an instance on Sunday 1 November to stop it with the command ./btcpay-down.sh, after reports that attackers were sweeping hot wallets on merchants’ servers. On Monday the project said it had found an attack vector aimed at version 2.4.1 and older and urged operators to update to 2.4.7, Cointelegraph reported. Nobody has published a loss figure, a count of affected servers or an explanation of how the attackers got in.
What BTCPay asked operators to do
- Stop the server. BTCPay posted this on X at about 22:25 UTC on Sunday, Bitcoin.com News reported: “If you’re running an instance, please shut it down (./btcpay-down.sh) until we complete the investigation.” That request named no version, so it covered every operator.
- Update to 2.4.7, the latest release at the time of writing. That second request came on Monday, according to Cointelegraph, in a BTCPay post on the attack vector.
- Report any theft. Cointelegraph says affected users were asked to send information and logs to the project’s security team, at [email protected] according to TokenPost.
BTCPay has not explained how those two requests fit together. Cointelegraph reports the shutdown warning and then the call to update without saying that one replaced the other, and we found no all-clear on BTCPay’s blog or its GitHub pages. The catch is in the update itself: BTCPay’s update script for Docker installs, btcpay-update.sh, ends by starting the stack again. A stopped server updated that way is therefore running before the project has said its investigation is complete. In anything we could read, BTCPay has not said when a stopped server can come back, or whether an update should wait until then.
A stopped server also takes no payments, since btcpay-down.sh stops and removes the stack’s containers. For a shop, then, the decision has a cost in sales on one side and the contents of a hot wallet on the other. The command itself belongs to the Docker deployment. Operators on other setups were covered by the same request but have to stop the service their own way.
What the founder said about the attack on BTCPay hot wallets
About two hours after the alert, founder Nicolas Dorier posted the first details. The reports “appear to involve BTCPay Server releases older than version 2.4.2”, he wrote, according to CoinDesk, and the project’s own public servers on 2.4.7 “were not attacked”. He also said the attacker had logged in as an administrator on the affected servers, and that the team did not yet know how that access was obtained.
Readers will see two wordings for the versions. “Older than 2.4.2” and “2.4.1 or earlier” describe the same releases, so the gap is only in the language. The change that does matter is from Dorier’s “appear to involve” to the stated attack vector of Monday, though no technical description of it has been published.
Neither statement covers the middle of the range. “We have no credible reports of hot wallet drains for users running the latest 2.4.7 release,” BTCPay wrote. Nothing we read says the same about 2.4.2 to 2.4.6, and CoinDesk noted that Dorier did not say newer versions are safe.
Only one business has been named. Bitcoin.com News says businesses including Coincards took their installations offline after the warning. That outlet reports no loss at Coincards or at any other merchant.
Why an administrator login can empty a hot wallet
BTCPay does not hold anyone’s money. Its documentation calls it “an open-source self-hosted software stack, not a company”: each merchant installs it on a machine they control and receives coins directly in their own wallet. That is self-custody applied to a shop till, and it explains the odd form of this alert. There is no central switch, as CoinDesk pointed out, so BTCPay could only ask each owner to act. No company holds a customer list to write to either, so a merchant who does not follow the project’s accounts may simply not have heard.
The software can run with two kinds of store wallet. In one, the server only knows public keys and watches for payments, while the private keys sit elsewhere, for example on a hardware wallet. In the other, a hot wallet, the seed phrase is stored on the server so that payments can be signed automatically. BTCPay’s wallet documentation puts this under a DANGER label: “Using the hot wallet feature comes with security implications”.
Automatic signing is the convenience, and it is also the exposure. Whoever controls the server can spend what the seed controls, in a single sweep that moves the coins out of the wallet. None of the main sources says that merchants without a hot wallet are hit, and BTCPay has not said they are safe. Its alert made no such distinction, although core contributor Uncle Rockstar Developer put it this way, according to Bitcoin.com News: “Not a drill: shut down your BTCPay Server if you have a hot wallet.”
Why 2.4.7 is not being called a fix
BTCPay has announced no patch for these thefts. Version 2.4.7 went out on 29 October at 13:48 UTC, a little over three days before the alert, so it was not written in response to it. It is the release for which the project has no credible reports of drains, which is a different claim from saying the hole is closed. The GitHub release notes do not connect any change to the November reports, and the same goes for the versions before it. This is what the notes say, release by release:
| Version | Date (2026) | What the release notes say |
|---|---|---|
| 2.4.1 | 23 July | Feature and fix release; BTCPay’s attack vector targets this version and older |
| 2.4.2 | 7 August | Fixes the critical flaw “being actively exploited” in August |
| 2.4.3 | 24 August | Security release, recommended for servers shared with many users |
| 2.4.4 | 7 September | Security update, according to BTCPay’s blog |
| 2.4.5 | 6 October | Blocks private-network destinations by default for outbound requests |
| 2.4.6 | 26 October | Broad security hardening |
| 2.4.7 | 29 October | 85 security findings fixed: 1 critical, 13 high, 52 medium, 19 low |
The 85 findings in 2.4.7 came from Anthropic’s OSS Scanner program, and the notes say the update is “highly recommended”, especially for servers shared by several merchants.
A new version also reaches nobody on its own. “Publishing fixes does not automatically update independently operated servers,” Bitcoin.com News wrote, and BTCPay’s documentation describes notifications of a new release, then an update the administrator starts from the Maintenance page or from a root shell. A server left on a July build has received none of the releases above unless someone installed them.
The August flaw hit Lightning nodes, and BTCPay cleared hot wallets then
This is BTCPay’s second emergency in under three months. On 7 August its security advisory said every version before 2.4.2 let an unauthenticated remote attacker obtain LND .macaroon credential files and take control of a merchant’s Lightning node. Funds were stolen. The named victims included Foundation, the hardware wallet maker, and Citadel21, according to CoinDesk, which added that Foundation’s on-chain hot wallet was untouched. BTCPay gave no total in the advisory or in its follow-up post of 10 August.
The instructions looked much like Sunday’s: update to 2.4.2, and LND users who could not do so right away were to take the server offline. The advisory, last updated on 30 October, still reads: “BTCPay Server’s on-chain wallets, including hot wallets, are not affected.” It also records a precaution of that week which BTCPay withdrew once it confirmed that only LND was hit. That August episode says nothing about what operators should do now.
That sentence describes the August flaw only. The new reports are about hot wallets, and the versions in question are the same ones August told operators to leave behind. Whether the two attacks are related is unknown. Cointelegraph says so directly, and BTCPay has not addressed it in anything we could read.
BTCPay has not told operators to move funds
Many operators will want to do more than switch off, so the status of those steps needs stating. In the coverage we read and on the project’s own pages, BTCPay has not told operators to move coins out of server-held wallets for this incident, and it has not told them to rotate passwords or API keys. Advice of that kind found elsewhere is not BTCPay’s.
Two older remarks can be mistaken for it. BTCPay’s post of 10 August favours cold storage as general practice, but it predates these reports and does not address them. Bitcoin.com News says Dorier reiterated the importance of limiting hot wallet balances to what operators can afford to lose, without presenting that as an instruction for this incident. Our guide to wallet types and custody explains the trade-off for readers weighing it up. Nothing in this article is a recommendation to move or hold any asset.
What nobody has said yet
- How much was taken. No total in bitcoin or dollars has been published.
- How many merchants or servers were hit.
- How the attacker obtained administrator access, and what the attack vector is.
- Whether operators should update now or stay offline, and when a stopped server can return.
- Whether releases from 2.4.2 to 2.4.6 are exposed, and whether 2.4.7 closes the route or simply has not been attacked.
- Whether the thefts are linked to the August flaw.
- Who is behind them. No on-chain addresses or transaction IDs have been published either.
The paper trail is thin for now. When we checked at about 05:50 UTC on Monday, BTCPay’s blog had no post on the incident (the latest is dated 5 October), the GitHub security advisories page was empty, no CVE number appeared in anything we read, and 2.4.7 was still the newest release. Cointelegraph said BTCPay had not answered its request for comment before publication.
CoinDesk placed the alert in the same week as the Binance hack, but no source links the two.
The next documents to watch are a BTCPay blog post or GitHub advisory giving the root cause, a 2.4.8 release, and any statement that stopped servers can return. We found nothing withdrawing Sunday’s request to stay offline.