Koinlytics

BTCPay Nodes Were Drained Before the Warning Went Public and the Patch Does Not Undo It

Aug 8, 2026BTCsecuritylightningbtcpayself-hostingexploits
A critical BTCPay Server flaw let unauthenticated attackers steal LND macaroon files and drain Lightning channels. Foundation and Citadel21 had nodes swept before the public advisory. Upgrading to 2.4.2 stops new access but does not invalidate stolen credentials.

BTCPay Server confirmed on August 7 that a critical vulnerability was being actively exploited against live servers. An unauthenticated remote attacker could obtain LND macaroon credential files, take control of the Lightning node they belonged to, and move funds out of its channels. The fix shipped as version 2.4.2.

Foundation, the company behind Passport hardware wallets, and Citadel21 both confirmed their Lightning nodes were swept before the public warning went live.

The Detail That Matters Most

Upgrading to 2.4.2 closes the hole. It does not help anyone whose credentials were already taken.

A macaroon is a bearer credential. Whoever holds it can act as the node operator, and the node has no way to distinguish the legitimate holder from a copy. Patching the software that leaked it changes nothing about the copies already in circulation.

The full remediation is three steps, and most coverage stopped at the first:

An operator who did only step one is running patched software with credentials that an attacker may still hold.

The Window Problem

The sequence here is the part worth studying. Researchers disclosed responsibly. The project prepared a fix. Between the moment the flaw became known to anyone outside the project and the moment operators could act on a public advisory, live nodes were emptied.

That window is structural, not a failure of process. Responsible disclosure exists because publishing a flaw before a patch exists is worse. But it means there is always an interval during which a small number of people know about an exploitable bug and the operators exposed to it do not.

For self-hosted infrastructure the practical consequence is that you cannot rely on being warned in time. You can only limit what a compromise costs.

A hot wallet on internet-facing infrastructure is not a wallet. It is an operating float, and it should hold what you can afford to lose in the window between a disclosure and your next patch cycle.

What BTCPay Did Right

The project donated 0.42 BTC to the researchers who reported the flaw and announced a bounty aimed at recovering the stolen funds. Both are the correct response and both are rarer than they should be in open source infrastructure, where security research is frequently rewarded with a thank-you note.

Paying for disclosure is not generosity. It is the cheapest way to ensure the next researcher who finds something brings it to you rather than selling it.

The Ten-Day Pattern

This lands inside a stretch that has been unusually bad for Bitcoin infrastructure specifically:

None of these were failures of Bitcoin. The protocol did exactly what it was told in every case. The failures were in a firmware build configuration, in a credential handling path, and in privileged key custody. The layer above the chain is where the money keeps leaving.

What to Watch

If you run a BTCPay instance, the concrete action is to revoke and regenerate macaroons and sweep any BTCPay-generated hot wallet, not simply to upgrade. And if you route merchant payments through Lightning, the size of the balance sitting in those channels at any moment is a risk parameter you set deliberately or one that gets set for you.

Powered by Koinlytics · Portfolio and DeFi analytics that see what others miss.

See every headline that moves your bag.

Koinlytics Market Intel is live inside the app. Track your portfolio, LPs and impermanent loss while the news breaks.

Join Koinlytics