BTCPay Told Bitcoin Merchants to Shut Down. Hot Wallets Are Getting Drained on Old Builds.

BTCPay Server told operators to shut down their servers after reports came in of unauthorized attackers draining funds from hot wallets, and the qualifier in that warning is the whole story: the thefts are hitting installs running outdated software.

That's it. No version number. No CVE. No count of affected merchants, no dollar figure, no indicators of compromise. Just: turn it off, then we'll talk.

For a project that quietly became the self-hosted checkout layer for a long tail of Bitcoin merchants, that's a blunt way to open a security incident. It's also the right first move. When you don't know the shape of the breach, you stop the bleeding before you write the postmortem.

The timeline

The sequence matters. Fund drains got reported to the project first. Not by a researcher filing a clean disclosure. By operators watching coins leave wallets they thought they controlled.

Then the public guidance landed: shut down your server. Then the narrowing: outdated software.

By November 1 the notice was circulating, and the practical instruction to operators was about as serious as it gets in payments. Don't just patch. Go offline. A payment processor telling merchants to stop accepting payments is a five-alarm decision, and nobody makes it on a hunch.

Here's the part that needs saying out loud. BTCPay is non-custodial by design. You run it yourself, it talks to your own Bitcoin node, it watches the chain, it sweeps incoming coins to a wallet you configure. That architecture is why merchants trust it. But if you configure a hot wallet, the keys sit on the same machine that faces the internet.

One skipped update is all it takes.

The trade-off was always explicit and always uncomfortable. Custodial processors hold your coins and take a cut. BTCPay holds nothing and takes nothing, and in exchange you become the sysadmin. Most merchants aren't sysadmins. They installed this thing once, years ago, on a $10 a month VPS, and haven't logged into the admin panel since.

That population is the target here. Not the well-staffed exchanges running hardened infrastructure. The bakery, the podcast, the solo dev selling API credits.

What actually broke

Two things, and only one of them is a bug.

The first is technical. Old builds with exposed hot wallets were reachable, and someone reached them. Whether that's an auth bypass, a leaked key path, a dependency with a known hole, or plain old default credentials on a server nobody hardened, we don't know yet. The project hasn't said. But the pattern is familiar. Attackers don't pick locks when a window is open. They scan, they fingerprint, they take.

The second failure is procedural, and it's the one I'd push on harder. A security notice without version numbers is a notice you can't act on. Which releases are affected? Which are safe? If a merchant is on a build from 2023 and one from 2025, does it matter? Right now the answer is a shrug.

Compare that to how the serious infrastructure projects handle this. A CVE, a fixed release, a severity score, a patched tag, and a clear statement of what a compromised box would look like. That's not bureaucracy. That's the difference between a merchant patching in twenty minutes and a merchant taking their whole checkout offline for three days because they've no idea if they're exposed.

And the money doesn't wait. Hot wallets on payment servers are working capital. They're the float. If a few wallets got drained, the losses are real but likely small in aggregate, because most operators sweep aggressively. The damage that scales is trust. A merchant who got hit once doesn't go back to self-hosting. They go back to a custodian with a support line and an SLA.

That's the irony worth sitting with. The best answer the industry has to custodial risk just handed its critics a case study in operational risk.

So who wins? Custodial processors, short term. Anyone selling managed BTCPay hosting with automatic updates, medium term. And the projects building version-checking and update nags into their admin panels, because this is the second time in memory that an old install has been the weak link in an otherwise sound design.

What happens next

Watch for three things, and give them a deadline.

First, a formal advisory with version numbers. If a week passes and operators still can't tell whether their build is affected, that's a bigger problem than the thefts. Second, a patched release, ideally with a migration note for anyone whose keys touched a compromised box. Rotating a hot wallet key isn't optional after a drain report, and it's the step people skip.

Third, disclosure process. A project this widely deployed needs a security.txt, a published policy, and a place to report. Permissionless money attracts permissionless attackers. The defense is boring, standardized, and written down.

Then there's the piece almost nobody is pricing in yet. We're pushing toward agentic payments, where software transacts on behalf of users, twenty-four seven, without a human approving each invoice. The compute layer needs a payment rail, and self-hosted processors are a natural fit because they don't ask permission.

But agents don't do maintenance windows. They don't notice a banner in an admin panel. They don't get an email about a security advisory and think, huh, I should patch that tonight.

If agents have wallets, who holds the keys? Fine question. Here's the harder one. Who patches the server the keys live on? Right now the answer is a human who forgot the login.

The AI-crypto Venn diagram is getting thicker, and this warning is a reminder that the plumbing underneath is still made of cron jobs and forgotten VPS instances. Self-custody is a security posture, not a security guarantee. It's a commitment to doing the unglamorous work forever.

Most people won't. That's the market signal hiding inside this incident, and the managed-hosting pitch writes itself.

For now, if you run BTCPay and you're not sure what version you're on, go find out. Before someone else does it for you.