What happened
On 7 August 2026 the BTCPay Server project published a
security advisory
telling operators to update immediately. The flaw, present in every version before 2.4.2,
"could allow an unauthenticated remote attacker to obtain .macaroon credential files for
LND", and those credentials "could be used to take control of an LND node and move funds". The
advisory does not describe this as a possibility: "We have confirmed that attackers exploited
this vulnerability. Users were affected and funds were stolen."
What it changes
A macaroon is not a password. It is a bearer credential, and LND's own documentation is
unambiguous about what that means: "Sharing a macaroon allows anyone in possession of that
macaroon to use it to access the service (in our case, lnd) to do anything permitted by the
macaroon"
(macaroons.md). LND
writes three of them to disk on startup. The one called admin.macaroon "contains a macaroon
with no caveats", which is the documentation's way of saying it can do everything.
There is no login step to fail, so reading the file is the whole attack. A password would have to be tried against a service that could rate-limit it or refuse it. A macaroon presented to the node is simply valid, because validity is a property of the bytes rather than of who is holding them.
The same LND document had already named the exposure: the macaroon files "are unencrypted and
in case of the admin.macaroon provide full access to the daemon. This can be seen as quite a
big security risk if the lnd daemon runs in an environment that is not fully trusted." It
goes further, calling them "the only files with highly sensitive information that are not
encrypted", unlike the wallet file and the macaroon database, which "are always encrypted, even
if no password is used". LND ships a stateless initialization mode that writes no macaroon
files at all, for exactly this reason. Every
merchant running a Lightning node through BTCPay had that
file on the same server as a web application reachable from the internet.
The remediation is correspondingly blunt. Updating to 2.4.2 also moves LND to 0.21.1 and regenerates the macaroons, which invalidates any copy an attacker took. Version 2.4.2 also "temporarily removes public access to the LND API on Docker deployments", so an external wallet such as Zeus can no longer reach the node through the BTCPay domain or its onion address. That is a working feature switched off deliberately while the incident is live.
On 10 August the project published its response, confirming that the vulnerability "allowed an attacker to obtain LND admin macaroon credentials from affected instances and use them to access connected LND wallets". The BTCPay Server Foundation said it would donate 0.21 BTC each to Craig Raw, who reported the flaw, and to the Bitcoin Red Team fund, and that supporters had committed to a recovery bounty of "10% of the amount recovered, up to a maximum of 3 BTC for full recovery of the funds".
What it does not change
It did not reach BTCPay's on-chain wallets. The advisory is specific, and corrects its own earlier caution: after further review the project confirmed "that only LND is impacted", and that "BTCPay Server's on-chain wallets, including hot wallets, are not affected". The exception is worth reading twice, because it is easy to mistake for the opposite: funds in LND's own on-chain wallet are part of the affected node and may still be at risk.
It does not reach other Lightning implementations. An operator running Core Lightning or Eclair behind BTCPay was never exposed to this particular credential risk, and the project says so rather than telling everyone they were breached.
Updating does not close a door you opened yourself. If the node is reachable through an operator's own reverse proxy, Tor service or forwarded port, "updating BTCPay Server does not close access paths that you manage separately", and those credentials still need rotating by hand. Neither does rotation undo the theft: new macaroons stop the old copies working, and the coins that already moved are gone.
And the mechanism is still not public. The advisory withheld technical details "because operators still need time to update", and as of 25 August 2026 the project's blog carries nothing further, so how the file read was reached is not something this post can tell you. What is known is the shape of the outcome, not the bug.
Context
The lesson here is not about Lightning being unsafe. It is about what a credential file is
once it is sitting on a machine that also answers requests from strangers. A signing key gets
treated with ceremony. A .macaroon looks like configuration, and it carries the same
authority.
That is also why the project's own advice, in a post about its own failure, is the ordinary advice: "keep funds in cold storage whenever possible. If you need a hot wallet for daily operations, regularly move excess funds to cold storage." A merchant node has to be hot to accept payments, which fixes the question at how much sits in it rather than whether it is exposed. The custody tradeoff does not disappear because the software is good; it moves to the balance.
The disclosure came from the same direction as several stories this month. Stratum V2's transport hardening and a splice input LDK now rejects both credit named audit teams, and the Bitcoin Red Team appears in this incident too. The difference is that those arrived as patches before anyone lost anything, and this one did not.