Bitcoin payments just got an urgent security wake-up call, and it comes from one of the most trusted names in self-custody infrastructure. BTCPay Server, the open-source Bitcoin payment platform that merchants around the world run on their own servers, has confirmed an attack vector affecting older versions of its software after receiving reports of attackers draining funds from users’ hot wallets. If you run a BTCPay instance, this is the week to stop scrolling and start updating.
What happened
The sequence of events unfolded fast. BTCPay first urged operators to shut down their server instances entirely while it investigated reports of unauthorized withdrawals from hot wallets, the online-connected wallets that payment processors keep liquid for making change and processing refunds. On Monday, the project announced the results of that investigation: an attack vector targeting instances running version 2.4.1 or earlier, a release that dates to July 23, 2026.
There is good news buried in the bad. The project said it has received no credible reports of hot wallet drains among users running its latest release, version 2.4.7, and it urged all operators to update their installations immediately. In other words, the fix already exists; the danger is concentrated in outdated deployments that have not been patched.
BTCPay has not disclosed how many operators were affected, how much has been stolen, or the technical details of how attackers accessed the wallets. The project asked affected users to submit information and logs to its security team, which means the full picture of the damage is still forming.
Why hot wallets are the target
The anatomy of the attack explains why this matters beyond the BTCPay community. A payment server’s hot wallet is, by design, internet-facing. It holds the coins the server needs to operate, which makes it the one place in a self-custody setup where convenience and exposure overlap. An attacker who finds a way into the server software does not need to break Bitcoin’s cryptography; they simply use the infrastructure’s own signing machinery against it.
That is also why this incident echoes an earlier one. Less than three months ago, BTCPay restricted remote Lightning access after an August attack that exploited a vulnerability to obtain Lightning Network Daemon credentials and steal funds. It remains unclear whether the latest attack vector is connected to that August vulnerability, but the pattern is the same: the soft target is not the blockchain, it is the operational software layered on top of it, and the exposure compounds when deployments fall behind on updates.
The uncomfortable economics of self-hosting
BTCPay Server’s value proposition has always been radical self-sovereignty: no payment processor, no intermediary, no one between you and your Bitcoin. That freedom carries a cost that this incident makes explicit, which is that the operator becomes their own security team. A merchant who spun up a BTCPay instance a year ago and let it run unattended may be running exactly the version range now being drained.
This is not an argument against self-hosting; it is an argument for treating self-hosted payment infrastructure like the production system it is. The projects that publish timely patches have done their job. The deployment gap between 2.4.1 and 2.4.7 is where the thefts live, and closing that gap is a human responsibility no protocol can automate away.
What Bitcoin merchants and users should do now
The practical checklist is short. First, if you operate a BTCPay Server, update to version 2.4.7 before doing anything else, and check your hot wallet’s transaction history for withdrawals you did not authorize. Second, limit what your hot wallet holds; keep only the float you genuinely need for operations in the online wallet and hold the rest in cold storage where an attacker cannot reach it. Third, treat any server that has been running unattended for months as suspect, because you cannot confirm what version it runs until you look.
For everyday Bitcoin holders, the relevance is more indirect but real. If you pay a merchant who self-hosts their payments, their security posture affects the continuity of the service and, in the worst case, whether the merchant survives the loss. And the wider lesson of this Bitcoin-security season, from wallet library bugs to payment server drains, is that the weakest link in self-custody is almost never the chain itself.
The bigger picture
This incident lands in the middle of the worst security stretch in crypto’s history, with the Binance hack still dominating headlines and the industry’s trust budget stretched thin. Open-source infrastructure like BTCPay remains one of the ecosystem’s genuine strengths, precisely because vulnerabilities get found, disclosed and patched in public. But patches only protect the people who install them. The gap between a security advisory and an operator’s update command is where funds disappear, and this week, that gap is measured in hot wallet balances.
Version 2.4.7 is a few minutes of work. For anyone still on 2.4.1, it may be the most profitable few minutes of the year.
Disclaimer: This article is for informational purposes only and does not constitute financial advice.
running a payment server on a july build with real float in the hot wallet is wild. 2.4.7 shipped for a reason ppl, this should be a 5 min fix
self custody doesnt mean set and forget. bet half the vulnerable instances havent been logged into since the day they were installed
five minutes if you remember your admin creds. helped a shop owner patch last week and he had not logged into that server since 2024. the update was the easy part
five minutes after you find the login. the real bottleneck is operators who never see the github notice because their integrator vanished back in 2023
self-hosting btcpay still beats a custodial processor but set-and-forget on a hot wallet holding your float is how you become the case study. the 2.4.7 update takes minutes
Two months unpatched matches what I see helping small shops in Porto. They treat btcpay like a plugin you install once and forget. The 2.4.7 update notice is probably sitting unread in an inbox nobody checks.
Worth noting 2.4.1 only shipped in July. Two months unpatched on internet-facing payment infra is rough, though sadly normal for small merchants juggling everything
juggling everything is exactly it. the merchant i help disabled auto updates because one broke his theme months ago. so the float sits in a hot wallet on a box nobody maintains
disabling auto updates over a theme break is treating two totally different risks as one thing. pin your plugins if you want, but a payment server holding float should get patched the day the notice drops
krystof july build on payment infra is rough but the docker tag pins make it worse. half those installs pull 2.4.1 forever because nobody updates the compose file
compose pins are the silent killer. half the 2.4.1 population does not even know what tag their stack pulls, the version on the dashboard is not the version running
minutes plus a rollback snapshot. updated two instances this morning, scariest part was how long the docker pull took on my rural connection lol
No figure on how much was drained is the detail that gets me. They are still collecting logs from affected operators, so the real number is probably still growing.
the no-number thing is standard for an open source project though. they only see what operators volunteer, actual drain sizes end up in police reports not github issues
right, and the operators who actually got drained are the least likely to volunteer logs publicly. we will learn the real number from a court filing months from now
second btcpay security thing since august and both touch lightning credentials. starting to think the lnd integration is the soft spot here
both incidents touching lightning creds makes sense, thats where the hot money lives. the onchain treasury sits cold, the ln wallet has to sign constantly, so thats the door attackers keep knocking on
the august one was lnd creds via remote access, this one they havent confirmed is related. same neighborhood though, i agree
lnd creds were the august thing. this one hit instances on 2.4.1 regardless of lightning setup, so blaming lnd conflates two different attack vectors
lndghost second lightning adjacent issue in a quarter, the lnd creds surface keeps being the target. core lightning looks better every month
maintainers already said 2.4.1 boxes got drained without lightning even configured. lnd catches the blame because thats where the stolen sats pass through, the actual door was the unpatched server itself
2.4.1 since july holding merchant float and no auto update path. update now or risk your float is the politest security headline of the year honestly