BTCPay Server tells operators to shut down as hot wallets are drained

The BTCPay payment server, which lets shops accept bitcoin without intermediaries, has come under attack: unknown actors have been draining funds from operators' hot wallets. On Monday the project team named the attack vector. Instances running version 2.4.1 and older were hit, while users of the current 2.4.7 release have reported no losses.

What is known about the vulnerable versions

BTCPay first urged operators to shut down their servers and published instructions for doing so. The team then checked the reports of unauthorized withdrawals and narrowed things down. According to Cointelegraph, the risk covers version 2.4.1 and earlier, and 2.4.1 came out on July 23, 2026. For release 2.4.7 there are no credible reports of drained wallets.

The scale is still unknown. The project has not disclosed the number of victims, the amount stolen or how the attack works. Anyone affected is asked to send logs to the security team.

For the market this is an awkward spot: the risk is real, yet it cannot be measured. So every operator has to act as if it applies to them.

Why merchants feel it first

BTCPay Server is open-source software that a merchant installs on their own server to take payment in Bitcoin with no payment middleman. The wallet is hot, with the keys sitting next to the shop itself. If the server is compromised, everything that has piled up is gone.

An exchange hack looks different. After the record $6.3 billion attack on Binance, outflows from the exchange reached billions of dollars, and self-custody is back in the conversation. The BTCPay case is a reminder that it is not free: security falls on the operator, who has to keep the software updated.

A string of self-custody failures since July

This is not the first blow in recent months. In August attackers exploited a vulnerability, obtained access to a Lightning node (LND) and moved funds out, after which BTCPay restricted remote Lightning access. Whether the new attack is linked to that vulnerability is still unclear.

In July about $100 million was stolen from Coldcard devices. A firmware flaw made some devices generate recovery phrases with too little randomness, and attackers reconstructed them. Users who had also set a strong passphrase stayed protected.

On Sunday Trezor raised the maximum length of its optional passphrase from 50 to 128 characters, citing the Coldcard episode. The new limit works in Trezor Suite with updated firmware, while older versions stay at 50 characters. Two days earlier the company had advised customers of its former reseller CryptoBilis who bought wallets since March to move funds to new devices. A buyer in Indonesia found a suspicious implant in a Trezor Safe 5 that could capture recovery phrases from the screen and send them over a cellular network. Trezor has not examined that device and says it has had no reports of losses.

What operators should do and where the risks remain

The practical minimum is clear, even if it guarantees nothing.

• A server on version 2.4.1 or older should be treated as unsafe until it is updated to 2.4.7.
• If an instance was switched off on the team's advice, update and review the logs before starting it again.
• A shop's hot wallet should not build up a large balance, and revenue is better moved to cold storage regularly.
• The link to the August LND vulnerability is neither confirmed nor ruled out, so relying on a single fix is not an option.

Ukrainian freelancers and merchants who take payment in bitcoin and immediately exchange bitcoin for hryvnia should pay particular attention. The shorter the funds sit in the server's hot wallet, the less there is to lose.

Where the simplicity of self-custody ends

Bitcoin payments rest on the idea that you can set up a server and collect money without a middleman. The string of failures since July shows how much maintenance sits behind that. Until BTCPay publishes technical details, the losses will be estimated by guesswork.