A single leaked macaroon file drained live LND nodes

What happened to BTCPay Server's LND nodes on August 7, 2026?

A single credential file — not a private key, not a seed phrase — was enough to empty live Lightning nodes belonging to real bitcoin merchants. The theft ran for roughly 20 hours before most operators knew anything was wrong.

On Friday, August 7, 2026, BTCPay Server published an emergency security advisory and shipped version 2.4.2 to close a critical vulnerability that was already being exploited against live merchant servers . The flaw let an unauthenticated remote attacker retrieve LND .macaroon credential files from affected instances — specifically the admin macaroon, which carries full authority over a node's wallet and channels. No private key theft was required: a valid control credential was enough to force-close channels and sweep the resulting on-chain outputs, according to the project's official advisory.

Every BTCPay Server version prior to 2.4.2 was exposed, including the 2.4.2 release candidates . Maintainer Nicolas Dorier cut the release the same day and did not soften the language in the release notes:

"This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can," — Nicolas Dorier, maintainer, BTCPay Server (source: v2.4.2 release notes, 2026-08).

Neither BTCPay nor subsequent reporting has disclosed a total victim count or total amount stolen. The only quantified picture is a third-party on-chain reconstruction by researcher somaxbt, which traced 2.21368911 BTC into two linked collector addresses from roughly 60 likely victim wallets between 01:17 and 20:52 UTC on August 7, across 72 drain transactions . That analysis attributes the activity on victim self-reports and timing rather than a direct exploit artifact, so treat it as a public floor — not a settled total (somaxbt, GitHub).

How a bearer-token credential became a full node takeover

A macaroon is a bearer token: whoever holds the file gets whatever access it encodes, with no second login, no device binding, and no session that an operator can revoke from a dashboard. LND's own documentation is explicit that anyone in possession of a macaroon can use it to access lnd for whatever that macaroon permits . That single design property is what converted an unauthenticated file-retrieval bug in BTCPay Server into unrestricted control of live Lightning nodes — the attacker did not need to break cryptography, only to read a file.

The specific file that mattered was admin.macaroon. LND generates three macaroons at startup — admin, read-only, and invoice — and the default admin macaroon is created with zero caveats, meaning no restriction on which RPC calls it can make, from where, or for how long . The same documentation treats those default files as unencrypted and highly sensitive, granting full daemon access in an untrusted environment . BTCPay's advisory describes the exploited flaw as unauthenticated remote retrieval of files with the .macaroon extension, and its later incident response identified the exposed credential as the LND admin macaroon that attackers used to reach connected wallets .

From there, the takeover ran through Lightning's own mechanics rather than through any custody breach. Holding admin authority, an attacker can instruct the node to force-close its payment channels, which unilaterally settles each channel and returns the local balance to the node's on-chain wallet as a set of UTXOs. Those outputs are then swept to attacker-controlled addresses. That two-step pattern — force-close, then sweep — matches both publicly confirmed cases. Foundation, the maker of the Passport hardware wallet, said attackers drained its BTCPay Lightning node overnight by force-closing channels and sweeping the resulting on-chain outputs; bitcoin publication Citadel21 reported its node was swept but held minimal funds . The mechanical signature is also visible in the third-party on-chain reconstruction, which counted 207 same-day channel-close UTXOs within its studied set .

What the attack did not touch is equally instructive. No BTCPay Server on-chain private keys were extracted, and BTCPay's review concluded that BTCPay Server on-chain wallets — including BTCPay hot wallets — were not affected by this credential-theft path. Funds sitting in LND's own on-chain wallet belong to the compromised node and remained at risk . Foundation's experience tracks that boundary precisely: its Lightning node was emptied while its BTCPay on-chain hot wallet went untouched . In other words, the breach lived entirely in the control plane. Operators reasoning about their exposure should separate two questions that are easy to conflate:

• Custody — who holds the seed and signing keys. Unchanged here; BTCPay's own wallet keys were never the target.
• Control — who can issue authenticated commands to a running daemon. This is what leaked, and for LND it is sufficient to move money.
• Implementation scope — nodes running Core Lightning or Eclair, and on-chain-only deployments, were not exposed to this credential path, though BTCPay advised everyone to update regardless .

Bearer credentials collapse those two questions into one. A file that can be copied silently, carries no expiry by default, and authorizes every RPC the daemon exposes is functionally equivalent to the funds it guards — a point that shapes every remediation step that follows.

Which node operators were actually exposed?

Exposure was narrower than the first advisory implied: only BTCPay Server instances using LND as their Lightning backend faced the credential-theft risk, and every version prior to 2.4.2 — including the 2.4.2 release candidates — was affected . After its own review, BTCPay confirmed that on-chain wallets managed by BTCPay Server, including BTCPay hot wallets, were not affected by this path; the funds genuinely at risk sat in LND's own on-chain wallet and in its payment channels .

That distinction matters for triage. An operator running BTCPay with Core Lightning or Eclair, or with no Lightning backend at all, was not exposed to the macaroon retrieval path, even while running a vulnerable version . The public victim pattern matches the technical scope: Foundation, the hardware-wallet maker behind the Passport device, had its BTCPay Lightning node drained overnight through force-closed channels and swept on-chain outputs, while its BTCPay on-chain hot wallet went untouched .

Containment came with a deliberate cost. Version 2.4.2 temporarily removed public access to the LND API on Docker deployments, which broke external-wallet connections made through a BTCPay domain or Tor onion address — tools such as Zeus lost remote node management until the project can restore the interface safely . Lightning payments themselves continued to route normally; only remote administration was withdrawn . Operators reading a dead Zeus connection as a second breach were seeing the fix, not the flaw (video: FatheryFinds).

The residual-risk group is the one worth flagging. A standard BTCPay update moves LND to 0.21.1 and regenerates its macaroons, but BTCPay states plainly that operators exposing LND through a reverse proxy, a separate Tor service, a forwarded port, or any route they manage outside BTCPay Server must rotate credentials themselves, because the update cannot close access paths the software does not control . Start9's BTCPay package documentation raises the same point for its 2.4.2:1 migration, surfacing critical credential-rotation tasks for Lightning backends and noting that older LND package behavior recreated macaroons without rotating the root key — leaving previously copied files valid, which is why its dependency floor requires LND 0.21.1-beta:11 or later for the revoke-macaroons action . In short: backend choice determined who was exposed, and network topology determines who still is.

The confirmed damage: Foundation, Citadel21, and the on-chain trail

Two named organizations have publicly confirmed losses from the BTCPay Server macaroon exploit: hardware-wallet maker Foundation, the company behind the Passport device, and the bitcoin publication Citadel21 . Foundation CEO Zach Herbert said attackers drained the company's BTCPay Lightning node overnight, force-closing its channels and sweeping the resulting on-chain outputs, while its BTCPay on-chain hot wallet was untouched . Citadel21 reported that its node was swept as well, but held minimal funds at the time .

The Foundation case is the clearest field evidence of what a stolen admin macaroon actually does in practice. Force-closing every channel and sweeping the resulting outputs is the mechanical signature of automated credential abuse, not of a private-key compromise — the on-chain hot wallet, which sits outside LND's control, survived intact . That split matches the scope the BTCPay project ultimately published: BTCPay on-chain wallets, including hot wallets, were not affected, while funds inside LND's own on-chain wallet belonged to the compromised node .

The only quantified picture of the drain comes from an independent on-chain analysis published by researcher somaxbt — explicitly not an official postmortem. It traced 2.21368911 BTC into two linked collector addresses from 60 likely wallets, with activity running from 01:17 to 20:52 UTC on August 7, 2026 .

Those figures carry an important caveat that responsible readers should not skip. The analysis attributes the activity to the BTCPay vulnerability on the basis of victim self-reports plus timing correlation, not a direct exploit artifact . It is a partial reconstruction: nodes drained through separate collector addresses, or operators who never came forward, would not appear in the studied set at all.

Neither BTCPay Server nor the outlets covering the incident have disclosed a total victim count or a total amount stolen . The project has confirmed the qualitative facts — the flaw was exploited, users were affected, and funds were stolen — without attaching numbers . For traders and operators sizing the risk, the practical reading is that 2.21368911 BTC is the documented floor and the ceiling remains unknown until the promised technical postmortem lands. As one independent review of the incident put it, the headline price action mattered far less than the fact that self-custodied routing capital could be swept in a single overnight window (video: FatheryFinds).

Why updating to 2.4.2 alone does not stop the bleeding

Patching a compromised BTCPay Server does not make it safe. The 2.4.2 release closes the unauthenticated file-retrieval path that let attackers pull .macaroon files, but it does nothing to invalidate a macaroon an attacker already copied . Macaroons are bearer tokens: a stolen copy stays valid until the credential itself is destroyed and regenerated at the node level. That is why a fully updated node can still be drained hours after the operator believes the incident is behind them.

A standard BTCPay Server update does handle part of this automatically. Applying the update moves the Lightning backend to LND 0.21.1 and regenerates the node's macaroons in the process, which invalidates the previously exfiltrated files for anyone reaching the node through BTCPay itself . The gap opens where the operator, not BTCPay, controls the access path. If LND is exposed through a reverse proxy, a Tor hidden service, a forwarded port, or any route configured outside BTCPay Server, the project states plainly that credentials must be rotated separately — the update cannot close doors it did not open .

Packaged deployments carry a subtler trap. Start9's BTCPay Server documentation flags credential rotation as a critical task in its 2.4.2:1 migration and points operators at the revoke-macaroons action for LND backends, while warning explicitly that updating alone does not undo access an attacker has already taken . Older LND package behavior recreated macaroon files without rotating the underlying root key — meaning the freshly written files looked new while previously copied macaroons remained cryptographically valid. That is the reason the dependency floor for revoke-macaroons is LND 0.21.1-beta:11 or later . An operator who regenerated files on an older package and assumed the job was done may still be holding an open door.

BTCPay's own remediation checklist for LND operators runs in a specific order, and skipping steps is what leaves nodes exposed :

• Update via Server Settings → Maintenance → Update, or take the server offline if updating is not immediately possible.
• Verify the version — the admin footer should read 2.4.2 and LND 0.21.1. Release candidates of 2.4.2 do not count as patched .
• Revoke and regenerate macaroons at the node level, not only through the BTCPay interface — mandatory for any independently exposed LND route.
• Move funds out of any BTCPay-generated on-chain hot wallet and recreate it, treating the old wallet as burned even though on-chain wallets were not the exfiltration target.
• Audit for compromise: unauthorized payments, unexpected channel closures, unfamiliar peers, and any gap between internal records and actual on-chain or channel balances.

That last item is the detection layer most operators lack. The drain pattern documented in the incident — force-closed channels followed by sweeps of the resulting on-chain outputs — produces exactly the signature the audit step is looking for . Integrators were also advised to move NBXplorer to 2.6.10 alongside the upgrade . One deliberate side effect of the containment: 2.4.2 temporarily removed public LND API access on Docker deployments, breaking remote node management through a BTCPay domain or onion address for tools such as Zeus. Lightning payments continued to function; only external node control was withdrawn .

BTCPay's response: bounties, disclosure credit, and what got fixed

The vulnerability reached BTCPay Server through private disclosure from the Bitcoin Red Team, a volunteer group that uses AI-assisted tooling to audit bitcoin open-source projects. Credited members include Craig Raw of Sparrow Wallet, Rob Hamilton, Calle, and Evan Kaloudis of ZEUS wallet . Raw disclosed that he was personally affected by the drain, which places the reporter inside the victim set rather than outside it — an unusual and verifiable form of first-hand incentive alignment.

The BTCPay Server Foundation attached money to that disclosure quickly. It pledged 0.21 BTC each to Craig Raw and to the Bitcoin Red Team fund for reporting the flaw responsibly, and project supporters separately committed a recovery bounty equal to 10% of any funds returned, capped at 3 BTC for full recovery . The structure is worth reading carefully: the disclosure payment is fixed and already earned, while the recovery bounty is contingent and addressed to whoever currently controls the stolen outputs. At bitcoin prices around the time of the offer, that 3 BTC ceiling was reported at roughly $190,000 .

Maintainer Nicolas Dorier also used the response window to correct the record. Claims circulated online that the exploited flaw was a previously known or previously disclosed issue; Dorier stated publicly that the bug was newly discovered by the Red Team, and committed the project to publishing a full technical postmortem . That distinction matters for operator liability and for trust in the project's disclosure process — a known-and-ignored bug and a zero-day reported in confidence produce very different conclusions about maintainer conduct.

"This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can," — Nicolas Dorier, maintainer, BTCPay Server (source: BTCPay Server v2.4.2 release notes).

Beyond the macaroon fix itself, version 2.4.2 carried several hardening changes that are frequently conflated with the exploited flaw but are technically separate :

• Greenfield Basic authentication disabled by default five minutes after account creation, narrowing a long-lived legacy auth surface.
• A TOTP two-factor-authentication bypass fixed — the bypass ran through Greenfield Basic auth and was not the actively exploited issue, despite appearing alongside it in some coverage.
• Public invoice-creation rate limiting added for payment requests, reducing abuse of unauthenticated endpoints.
• NBXplorer 2.6.10 recommended for integrators shipping the update.

The official advisory frames the actively exploited issue strictly as unauthenticated retrieval of .macaroon files, not as the TOTP bypass . BTCPay says it is cooperating with exchanges, blockchain analytics firms, and law-enforcement authorities on tracing and freezing funds, and that it is adding external code-scanning and review processes while prioritizing security patches and hardening over major new features for the foreseeable future . That prioritization shift showed up in shipping cadence: version 2.4.4, released September 7, 2026, added hashed API-key storage, removed legacy BitPay Basic-auth keys, corrected invoice permissions, and blocked script injection through support links . One independent commentator framed the episode as a credential-handling failure rather than a bitcoin protocol failure, noting that the network itself never broke while operator-controlled keys did (video: FatheryFinds).

What this means for Lightning infrastructure risk going forward

The durable lesson from the August 2026 drain is that self-hosted Lightning nodes carry a credential-management risk that sits entirely outside on-chain custody protections and can bypass them. Foundation's BTCPay on-chain hot wallet survived untouched while its Lightning node was emptied overnight . Seed backups, hardware signers, and wallet passphrases offer no defense against a bearer token that already authorizes force-closes and sweeps. For operators, the risk surface is a file, not a key.

That distinction reframes how self-hosted payment infrastructure should be assessed. A node's threat model has to cover the full set of paths through which a .macaroon can be read or copied — reverse proxies, Tor hidden services, forwarded ports, backups, and container volumes — because each is an independent exfiltration route that a software update does not close . Rotation cadence, not just patch cadence, becomes the operational metric that matters.

Recovery of the stolen funds remains open. BTCPay Server says it is cooperating with exchanges, blockchain analytics providers, and law-enforcement authorities on tracing and freezing the proceeds, but no recovery timeline has been confirmed, and neither the total victim count nor the total amount taken has been published . The only quantified public picture is still a third-party on-chain reconstruction that traced 2.21368911 BTC into two linked collector addresses across 72 drain transactions . Operators waiting on restitution should plan as if none arrives.

On the development side, the project has stated it will prioritize security patches and hardening over major new features for the foreseeable future, and is introducing stronger code-scanning and external review processes with outside organizations . The pace since the incident supports that claim rather than leaving it as a statement of intent.

The direction of the 2.4.4 changes is the signal worth reading. Hashing stored API keys and deleting the legacy BitPay Basic-authentication path both attack the same structural weakness the drain exposed: long-lived, plaintext, replayable credentials sitting on a server that faces the internet . Thirty-one days separated the emergency patch from that follow-up, which is a reasonable proxy for how seriously the maintainers are treating credential architecture rather than only the single exploited endpoint.

Two questions stay unresolved and should temper any conclusion that the chapter is closed: the full technical root cause has not been published — details were withheld to give operators time to update — and it is unknown whether the traced funds remain unmoved . Until the postmortem lands, operators are working from advisory guidance rather than a complete picture of what was exploited.

Operator action checklist: are you still exposed?

An operator is still exposed if any LND instance that existed before August 7, 2026 is running with macaroons that were never revoked and regenerated at the node level. Patching is the first step, not the finish line: updating to BTCPay Server 2.4.2 stops further credential exfiltration but leaves already-copied bearer tokens valid until the macaroon root key is rotated . Work through the following in order rather than stopping at the version number.

• Verify the version before assuming safety. Open Server Settings → Maintenance → Update, then confirm the admin footer reports BTCPay Server 2.4.2 and LND 0.21.1. Every release before 2.4.2, including the 2.4.2 release candidates, was affected . Current deployments can go further: 2.4.4, released September 7, 2026, adds hashed API-key storage and removes legacy BitPay Basic-auth keys .
• Rotate, don't just update. A standard BTCPay update regenerates LND's macaroons, but if LND is reachable outside BTCPay's managed proxy — a reverse proxy, Tor hidden service, or forwarded port — run a node-level revocation yourself. On Start9, that is the revoke-macaroons action, which requires LND 0.21.1-beta:11 or later because earlier packages recreated macaroon files without rotating the root key, leaving copies valid .
• Recreate BTCPay-generated on-chain hot wallets. Move the balance out and rebuild the wallet rather than trusting the old address set .
• Audit around the incident window. Check channel history for force-closures, unfamiliar peers, unauthorized payments, and gaps between internal records and actual on-chain or channel balances. The public on-chain reconstruction places drain activity between 01:17 and 20:52 UTC on August 7, 2026, across 72 transactions and 207 same-day channel-close outputs — a narrow window to reconcile against.

One operational caveat: 2.4.2 temporarily withdrew public LND API access on Docker deployments, so external wallet tools such as Zeus lose remote node management until that path is restored. Lightning payments themselves keep working (video: FatheryFinds). The concrete takeaway for any Lightning operator: treat credential rotation as a mandatory second step after every disclosure, and verify it at the node — because a fully patched server running old macaroons is still an open door.

Frequently asked questions

What is a macaroon in LND, and why is it dangerous if leaked?

A macaroon is a bearer credential that LND generates at startup to authenticate API calls to the node. LND creates three of them — admin, read-only, and invoice — and the default admin.macaroon is issued without caveats, meaning it carries unrestricted administrative authority over the daemon . Because it is a bearer token, possession alone is sufficient: whoever holds the file can use it for whatever it permits, with no password prompt, no second factor, and no need to steal the node's private keys. LND's own documentation describes the default macaroon files as unencrypted and highly sensitive in an untrusted environment . That design is exactly what made the August 2026 BTCPay Server flaw so damaging — an attacker who retrieved a .macaroon file could force-close channels and sweep the resulting on-chain outputs, as the BTCPay Server security advisory describes.

Is BTCPay Server safe to use after the 2.4.2 patch?

The exfiltration path is closed in BTCPay Server 2.4.2, released August 7, 2026, but patching alone does not make a previously exposed node safe . Updating stops further credential theft; it does not invalidate macaroons an attacker already copied, and those remain valid until they are destroyed and regenerated. A standard BTCPay update moves LND to 0.21.1 and regenerates its macaroons, but BTCPay warns that operators who expose LND independently — through a reverse proxy, Tor service, or forwarded port — must rotate credentials separately, because the update cannot close access paths the operator manages outside BTCPay Server . The project has since shipped further hardening in 2.4.4 on September 7, 2026, including hashed API-key storage and removal of legacy BitPay Basic-auth keys . Patch plus rotation plus verification — not patch alone.

Were BTCPay Server's own funds or on-chain wallets affected?

No. BTCPay initially urged extra caution around on-chain wallets, but the project's subsequent review concluded that BTCPay Server on-chain wallets, including BTCPay hot wallets, were not affected by this vulnerability . The exposure ran through the stolen LND admin macaroon, so what was at risk was the LND node itself: its channel balances and the coins held in LND's own on-chain wallet. The real-world outcome matched that boundary. Hardware-wallet maker Foundation reported that attackers drained its BTCPay Lightning node overnight and swept the resulting on-chain outputs after force-closing channels, while its BTCPay on-chain hot wallet went untouched . BTCPay still advises moving funds out of any BTCPay-generated on-chain hot wallet and recreating it as a precaution.

How much was stolen in the BTCPay Server LND exploit?

There is no official total. BTCPay has confirmed that the flaw was exploited, that users were affected, and that funds were stolen, but neither the project nor press reporting has disclosed the number of compromised operators or the aggregate amount taken . The only quantified picture comes from an independent on-chain analysis published by researcher somaxbt, which traced 2.21368911 BTC into two linked collector addresses from roughly 60 likely wallets between 01:17 and 20:52 UTC on August 7, 2026, spanning 72 drain transactions, 556 distinct victim addresses, 559 spent UTXOs, and 207 same-day channel-close outputs . That work attributes the activity on the basis of victim self-reports and timing rather than a direct exploit artifact, so treat 2.21 BTC as a public floor and partial reconstruction, not a settled final figure.

Does this vulnerability affect Core Lightning or Eclair users?

No. BTCPay Server's review found the credential-theft risk specific to LND's macaroon model, and the attacks the project examined targeted files with the .macaroon extension. Operators running Core Lightning or Eclair as their Lightning backend, and those running on-chain-only deployments, were not exposed to this path . That said, every BTCPay Server version prior to 2.4.2 was affected, including the 2.4.2 release candidates, and the same release fixed a TOTP two-factor-authentication bypass via Greenfield Basic authentication, disabled Greenfield Basic authentication by default five minutes after account creation, and added rate limiting on public invoice creation . Non-LND operators should still update for those unrelated fixes.

Enjoyed this article? Subscribe to get new stories by email whenever they're published.

Subscribe