Mentioned in This Article
1. Why did BTCPay Server tell users to shut down?
Reports of a BTCPay Server hack led the free open-source bitcoin payment software's maintainers to urge all operators, on Sunday, November 1, to switch off their servers. Attackers are said to have drained hot wallets, and the project has given no loss figure or fix. Founder Nicolas Dorier said the thefts appear to involve versions older than 2.4.2.
The request came after BTCPay received reports that unauthorized parties were emptying hot wallets hosted on some of its servers. In a post on X, the project asked anyone running an instance to shut it down using a provided shutdown script and to keep it offline until the investigation is complete. The script halts the software; it does not move or secure any funds on its own.
The project did not limit its request to a particular release. It named no software versions in the initial alert and announced no patch, which meant that every operator was asked to stop, whatever version they were running. That blanket instruction is unusual for a payment tool, and it reflects how little the maintainers knew when they issued it.
2. How BTCPay Server works and where the risk sits
BTCPay Server lets a business receive bitcoin directly, with no payment processor or custodian in the middle. Anyone can deploy the software on their own machine, and those servers run continuously so that they can detect incoming payments and generate invoices at any hour. Because merchants control the whole stack, the funds they receive go to wallets they manage rather than to a third party.
The software allows merchants to run hot wallets, meaning wallets that stay connected to the internet. In that setup the seed phrase, the secret string required to authorize spending, is stored on the merchant's own server. A wallet can accept payments without holding the seed, but the server can only send coins if it has it.
BTCPay's own documentation describes the relevant feature in blunt terms. When the seed is stored on the server, the software will automatically use it to sign transactions, and the documentation labels this option with the word "DANGER" and a warning about its security implications. The consequence is that no separate device or manual approval stands between a request to send funds and the coins leaving the wallet.
This convenience carries a clear trade-off. Anyone who gains control of such a server can instruct it to send the coins to an address of their choosing. The security of the funds is only as strong as the security of the machine that holds the seed.
3. What happened to the affected wallets?
According to the project's description, the affected wallets were swept. In bitcoin terminology, a sweep moves the entire balance out of a wallet in a single transaction, which is what an attacker typically does once they can sign on a victim's behalf. Reports of such sweeps on merchant servers are what prompted the shutdown request.
About two hours after the first alert, Dorier added detail on X. He said the thefts appear to involve releases older than 2.4.2, in other words servers that have not been updated to that version or any later one. He also said that BTCPay's own public servers, which run version 2.4.7, were not attacked.
Dorier also said that on the affected servers, the attacker logged in as an administrator, an account with top-level control over the installation. The team does not yet know how the attacker obtained that access. Without that answer, the maintainers cannot say whether the weakness is a flaw in the software, stolen credentials or something else.
4. What remains unknown about newer versions?
The most important open question is whether versions at or above 2.4.2 are safe. Dorier did not say that they are. The fact that BTCPay's public servers on version 2.4.7 were untouched is encouraging, but it is evidence from a handful of machines and does not establish that the wider population of newer installations is protected.
The project has also not said how many servers were drained, how much bitcoin was taken or whether the thefts are continuing. It has not named a cause, and it has not set a timeline for the end of the investigation. Until those points are answered, operators who comply with the shutdown request have no date on which to expect their payment systems to return.
For merchants, the practical effect is that they may be unable to accept bitcoin through their own BTCPay instance for the time being. Businesses that depend on the tool for checkout will need to decide whether to wait or to arrange alternative payment methods.
5. Is this BTCPay's first security problem this year?
No. In August, BTCPay confirmed that attackers had stolen funds by exploiting a flaw in versions released before 2.4.2. That flaw allowed outsiders to obtain credential files for LND, a widely used Lightning Network node software. With those credentials, an attacker could take control of a node and move the funds it managed.
BTCPay fixed that earlier flaw in version 2.4.2, which is the same version number now at the center of the latest reports. The overlap does not prove that the two incidents are connected, and the project has not said that they are. It does explain why the maintainers and users alike are focused on installations that were never updated past that release.
6. Why self-hosted payment tools need a different kind of response
The decentralized design that makes BTCPay attractive also shapes how it can respond to an emergency. Each merchant hosts a separate server, so there is no central switch the project can flip to stop an attack. A hosted payment processor can freeze accounts or push a fix to all customers at once; BTCPay cannot shut down anyone's machine for them.
That is why the project had to ask operators one by one, through a public post, to turn their servers off. Each owner is responsible for securing their own infrastructure, applying updates and deciding how much money to keep in a hot wallet. When a vulnerability appears, how quickly it is contained depends on how many operators see the warning and act on it.
The incident arrived days after the Binance theft, in which an exploiter drained cryptocurrency worth more than $6 billion in what has been described as the largest exploit in crypto history. The two cases differ enormously in scale and mechanism, but both have put the custody of digital assets back in the spotlight.
7. What should BTCPay operators do now?
The project's direction is straightforward: shut down any running instance with the supplied script and leave it off until BTCPay says the investigation is finished. Operators running versions older than 2.4.2 are the ones the early reports point to, although the project has not cleared newer versions.
Security practice in general favors limiting how much value sits in a hot wallet connected to a server, and keeping the bulk of funds in storage where spending requires a separate device. BTCPay's documentation already steers users away from storing the seed on the server for that reason.
The next development to watch is a statement from the BTCPay team on the cause of the administrator access, any loss estimate and a patched release. Until it appears, the guidance stands as issued on Sunday: switch the server off and wait.
8. Hot wallets versus cold storage: why the distinction matters
A wallet's exposure depends largely on where its private keys live. A hot wallet keeps them on a device that is online, which makes spending fast and automatic but also makes the keys reachable by anyone who can break into that device. Cold storage keeps the keys offline, for example on a dedicated hardware device, so that a remote attacker has nothing to steal from the server itself.
For a business that takes many small payments, a hot wallet is attractive because incoming funds appear instantly and no staff member has to approve each transaction. The common compromise is to treat the hot wallet like a till: keep only the amount needed for day-to-day operations in it, and regularly move the rest to storage that requires a manual, offline signature.
The BTCPay reports illustrate why that discipline matters. If an attacker obtains administrator rights on a server that holds a seed and signs automatically, the size of the loss is simply the size of the balance sitting in the wallet at that moment. Merchants who swept their takings into offline storage each day would have exposed far less.
9. Why open-source payment software attracts attackers
Software that handles money is a natural target, and open-source projects add a particular dynamic. The code is public, which allows independent researchers to audit it and report flaws, but it also lets attackers study the same code for weaknesses. Whether the balance tips toward defenders usually depends on how fast fixes are written and how quickly users install them.
Self-hosted deployments make the second half of that equation harder. A merchant who set up a server a year or two ago and never revisited it can be running a version that has long since been superseded. Public disclosure of a fixed bug then becomes a map for attackers, who look for installations that have not applied the update.
None of this is specific to bitcoin, but the irreversibility of blockchain transactions raises the stakes. Once coins leave a wallet and are confirmed on the network, there is no bank to call and no chargeback process, which is why operators of this kind of software are advised to treat updates and access controls as routine, urgent maintenance.