BTCPay Server Lightning Exploit: Patched Isn't Safe

BTCPay Server, the open-source payment processor thousands of merchants and self-hosted node runners use to accept bitcoin, shipped an emergency fix on Friday after researchers found a flaw letting remote attackers pull credential files off installs running LND, the most common Lightning Network backend. Those files, called macaroons, work like admin passwords for a node — whoever holds one can move funds, close channels and drain a wallet without needing a second factor. BTCPay's advisory credits the discovery to Bitcoin Red Team and says version 2.4.2, paired with LND 0.21.1, closes the access path. Two operators have already confirmed losses: Foundation, the hardware wallet maker, said its node was drained overnight, and Citadel21 had its channels force-closed in a sweep flagged publicly by Hodlonaut. Neither BTCPay nor the victims have put a total dollar figure on losses so far.

That much is now widely reported. What most coverage glosses over is the part that actually determines whether you're still exposed today: patching does not undo a theft that already happened.

Not on its own. BTCPay's own advisory draws a distinction that's easy to miss in a headline: the update stops an attacker from newly stealing your macaroon, but it does nothing to a macaroon someone already took. A macaroon is just a credential — the update doesn't expire it, rotate it, or notice it's in the wrong hands. If your node was hit before you patched, the same file an attacker grabbed last week still authenticates against your node this week, patch or no patch.

BTCPay is asking operators to treat this as a two-step job. Step one is the software update. Step two — separate, manual, and easy to skip — is regenerating macaroons.db and rotating the Lightning backend's auth strings, which forces every existing credential to expire and issues fresh ones. Skip step two and you've closed the front door while the attacker still has a key to the one you already installed. BTCPay's guidance is blunt about this: treat any pre-2.4.2 install, including release candidates, as compromised until you've done the rotation, not just the update.

This is the mechanism behind the reader question this piece is answering. If you patched to 2.4.2 and stopped there, you have addressed future risk, not past risk. The two are genuinely separate problems, and only one of them gets fixed by clicking "update."

The two named victims so far — Foundation and Citadel21 — disclosed within about a day of the advisory going out, which is fast by infrastructure-hack standards. That speed cuts against complacency: this isn't a theoretical bug, it produced real, quick losses at organizations that presumably watch their own infrastructure closely. It also means the confirmed count is almost certainly a floor, not a ceiling. An attacker sitting on a valid macaroon has no reason to act immediately — they can wait, watch channel balances build back up, and drain later, which means quieter node operators may not know yet that they're compromised. BTCPay has not published a total server count or an aggregate bitcoin figure, and a formal CVE and post-mortem — likely, given the Bitcoin Red Team disclosure credit — would be the point where a fuller picture emerges.

The scope here is narrower than some of the more alarmed coverage implies. BTCPay says the credential-exposure path is specific to installs using LND as the Lightning backend. If you're running Core Lightning or Eclair instead, this particular flaw doesn't apply to you, and BTCPay's own on-chain and hot-wallet functions sit outside it too. That's a meaningful distinction for anyone trying to triage urgency rather than just reacting to a scary headline.

The bigger practical gap is timing, not backend choice. Most self-hosted node operators don't run upstream BTCPay directly — they run it bundled inside a distro like Start9, Umbrel, myNode or RaspiBlitz. Those projects maintain their own builds and typically ship a fix days to weeks after the upstream patch lands, not the same day. If you're on one of those platforms, checking "am I on 2.4.2" may return yes for the underlying software while your distro's version still ships the vulnerable build, or vice versa — check your specific distro's release notes rather than assuming upstream timing applies to you.

If you run BTCPay with LND, the sequence matters. First, confirm you're on 2.4.2 with LND 0.21.1 — check your distro's own advisory if you're on Start9, Umbrel, myNode or RaspiBlitz, since their release cadence lags upstream. Second, and this is the step reporting keeps underselling, regenerate macaroons.db and rotate your Lightning backend's auth strings regardless of whether you've seen anything unusual. Third, check recent channel activity and balances for anything you didn't initiate; a quiet drain can look like normal channel management until you total it up. None of this requires touching a hot wallet outside the LND-backed setup this flaw targets, so operators on Core Lightning or Eclair can treat this as a lower-urgency read, not a non-issue.

The likely trajectory over the next several days is more disclosures, not fewer, as operators comb their own logs and distro maintainers catch up with their builds. That's a sign the fix is working its way through the ecosystem, not a sign the problem is spreading — but until macaroon rotation catches up with patch adoption, "updated" and "safe" are going to keep meaning different things for a meaningful slice of BTCPay's self-hosted user base.