One leaked file was enough to sweep a Lightning node

What Happened to BTCPay Server's Lightning Nodes?

A payment processor that thousands of merchants run themselves shipped an emergency patch on a Friday — and by then, attackers had already been inside for long enough to empty Lightning channels.

On August 7, 2026, BTCPay Server published a security advisory and released version 2.4.2 to close a critical vulnerability that was already being exploited in the wild . The flaw let an unauthenticated remote attacker retrieve .macaroon credential files from a connected LND (Lightning Network Daemon) node. A macaroon is LND's bearer-token API credential — anyone holding an admin macaroon controls the node outright, including the ability to open and close payment channels and move funds . Attackers used stolen macaroons to force-close channels and sweep merchant Lightning balances before many operators had applied the patch .

Quick Answer: BTCPay Server v2.4.2, released August 7, 2026, patches an actively exploited flaw that let unauthenticated attackers steal LND .macaroon files — bearer tokens granting full node control. Every release before 2.4.2, including its release candidates, is affected. Patching alone does not revoke already-stolen credentials.

The exposure is broad in version terms and narrow in configuration terms. Every BTCPay Server release prior to 2.4.2 is affected, including the 2.4.2 release candidates . The credential-theft path itself applies specifically to deployments using LND as the Lightning backend; other Lightning implementations and on-chain-only BTCPay installations were not exposed through this particular route, though the project told every operator to update regardless .

One distinction matters for anyone assessing their own exposure. BTCPay's own on-chain wallets, including hot wallets, were not directly compromised by the macaroon leak. But bitcoin sitting in LND's internal on-chain wallet is controlled by the compromised node — and was therefore squarely at risk . That is precisely the pattern confirmed victims described: channels force-closed and drained while separate hot wallets sat untouched.

Operators unable to update immediately were told to take the server offline entirely rather than leave it reachable . That instruction — shut down, not just patch later — is the clearest signal of how the project assessed the risk in the first 24 hours. Market reaction, by contrast, was muted: spot bitcoin markets largely shrugged the incident off, which says more about how infrastructure risk is priced than about how serious the breach was for the merchants who lost funds (video: FatheryFinds).

How the Macaroon Exploit Actually Worked

A macaroon is LND's bearer-token API credential — a small binary file that authenticates any request presenting it, with no password, session, or second factor attached. Whoever holds an admin macaroon holds the node: they can open and close payment channels, move funds, and issue any other privileged command against the daemon . The BTCPay Server flaw patched in v2.4.2 let an unauthenticated remote attacker retrieve those .macaroon files from a connected LND node . From there, no exploit chain was needed — the attacker simply used the credential as intended, and the node obeyed.

That design is what makes bearer tokens efficient and what makes their leakage terminal. There is no per-request identity check to fail, no anomaly in the authentication log to trip an alarm, and no built-in expiry to run out the clock. Attackers used the stolen macaroons to sweep merchant Lightning channels before many operators had applied the patch . To the node, those were legitimate admin instructions.

The blast radius is easy to misread, so it is worth stating precisely. BTCPay Server's own wallets — including hot on-chain wallets created inside BTCPay — were not directly compromised by the macaroon leak . But LND maintains its own internal on-chain wallet, separate from BTCPay's, and that wallet answers to the node the attacker now controlled. Bitcoin sitting there was exposed, as were channel balances that could be force-closed and swept . The distinction matters operationally: an operator who checked only their BTCPay wallet balance and found it intact could still have been drained on the LND side.

Exposure to this specific path came down to backend choice and version:

• Exposed: every BTCPay Server release prior to 2.4.2, including the 2.4.2 release candidates, running LND as the Lightning backend .
• Outside this path: deployments using other Lightning implementations, and on-chain-only BTCPay instances with no Lightning backend attached .
• Still told to update: all operators regardless of backend — v2.4.2 also carried an unrelated fix for a TOTP two-factor bypass in the Greenfield API via Basic authentication, reported as issue #7491 by @brunoerg and @benthecarman of the Bitcoin Red Team .

Standard Docker deployments upgraded to LND 0.21.1 as part of v2.4.2, and integrators were separately directed to NBXplorer 2.6.10 . Being outside the LND path was a matter of architecture, not diligence — which is the uncomfortable part for anyone who happened to pick the affected stack.

Who Got Drained: Confirmed Victims and Losses

Two organizations have publicly confirmed losing Lightning funds in the BTCPay Server macaroon exploit: Foundation, the company behind the Passport hardware wallet, and Citadel21, a Bitcoin zine. Foundation's Lightning node was drained overnight, with channels force-closed and balances swept, while its hot wallet was untouched . Citadel21 confirmed its node was swept as well but said it held minimal funds there at the time . Beyond those two, the victim count is unknown.

Foundation's disclosure is the most detailed public account so far. CEO Zach Herbert described the node being emptied while the team slept, an attack pattern consistent with automated use of a stolen admin macaroon: force-close the channels, then sweep the resulting on-chain outputs .

"Our Lightning node was drained overnight — channels force-closed and funds swept. Our hot wallet was not touched," — Zach Herbert, CEO at Foundation (source: Cointelegraph, reported 2026-08).

The split between what was taken and what survived matters for anyone auditing their own exposure. BTCPay's own on-chain wallets, including hot wallets created inside BTCPay, were not directly compromised by the credential leak. What sat inside LND's internal on-chain wallet, however, was controlled by the compromised node and was therefore in scope . Foundation's outcome — Lightning gone, hot wallet intact — is exactly the boundary the advisory describes.

BTCPay Server has not published how many operators were compromised or the total amount of bitcoin stolen. Both numbers are expected in a postmortem the project has said it will release . That silence is not necessarily evasion — reconstructing losses across self-hosted, independently operated nodes is genuinely hard, since no central party sees the balances — but it does mean the current public tally is a floor, not a total.

Some scale can be inferred from the response rather than the reporting. On August 10, 2026, supporters announced a recovery bounty of 10% of any recovered funds, capped at 3 BTC, which implies a stolen sum large enough to make a seven-figure-sat incentive worthwhile . For comparison within the same reporting window, a separate Coldcard-related exploit accounted for roughly $116 million in confirmed losses — an order of magnitude that this incident, on the evidence published so far, does not appear to approach . Spot markets, for their part, largely shrugged off the news (video: FatheryFinds).

One practical read for operators: the two confirmed victims were both bitcoin-native organizations with technically capable teams, and the difference in outcome between them came down to how much was parked in channels, not to how carefully they were run. Balance size on a self-hosted node was the deciding variable .

Why Updating to v2.4.2 Alone Doesn't Save You

Installing BTCPay Server 2.4.2 closes the exfiltration path, but it does not invalidate macaroons an attacker already copied. Macaroons are bearer credentials: whoever holds the file can use it, and it stays valid until the credential is destroyed and reissued . An operator who patched on August 7 and stopped there may still be running a node an attacker can command through a copy taken days earlier . Patching is step one of four, not the whole job.

BTCPay's published remediation runs in sequence, and skipping a step leaves the previous one incomplete:

• Update. Server Settings → Maintenance → Update, moving to 2.4.2. Every release before it is affected, including the 2.4.2 release candidates .
• Regenerate macaroons and macaroons.db. This is what actually revokes the stolen credential; the update alone does not .
• Rotate authentication strings for any other Lightning backend connected to the instance, not just LND .
• Move and recreate any hot on-chain wallet generated inside BTCPay. Those wallets were not directly compromised by the leak, but the guidance is to move the funds and recreate the wallet anyway .

Standard Docker deployments get some of this automatically. Version 2.4.2 upgrades those installs to LND 0.21.1 and regenerates macaroon credentials as part of the update, and integrators were separately told to move to NBXplorer 2.6.10 . The automation stops at the boundary of what BTCPay manages. Operators who expose LND independently — behind their own reverse proxy, through a self-managed Tor hidden service, or via a forwarded port — have to rotate credentials themselves, because the update cannot close an access route it never controlled . That is precisely the group most likely to assume the update handled everything: advanced setups with custom networking are the ones the automatic path skips.

For anyone who could not update immediately, the instruction was blunt — take the server offline rather than leave it reachable . BTCPay also temporarily removed public remote access to the LND API on Docker deployments, which is why external wallets such as Zeus can no longer connect to LND through a BTCPay domain or onion address until the project judges it safe to restore . Lightning payments themselves keep working; the remote-management convenience is what was withdrawn.

The final step is forensic rather than mechanical. BTCPay asked operators to audit their nodes for four specific signals: unauthorized payments, unexpected channel closures, unfamiliar peers, and discrepancies between internal records and on-chain or Lightning balances . Those map directly onto how the confirmed drains looked in practice — force-closed channels and swept funds appearing overnight . A clean audit after a full credential rotation is the only evidence an operator has that the incident ended for them; a patched version number is not.

BTCPay's Emergency Response, Day by Day

BTCPay Server's response ran on a three-day clock: the security advisory and the v2.4.2 emergency patch both landed on August 7, 2026, while the flaw was already being exploited . The same day, the project pulled public remote access to the LND API on Docker deployments — a defensive rollback rather than a bug fix. By August 10, supporters had attached money to the cleanup, announcing a recovery bounty worth 10% of any recovered funds, capped at 3 BTC .

The remote-access rollback is the change most operators will feel day to day. Payments continue to settle through the node, but the convenience layer — managing an LND backend from a phone wallet over a public endpoint — is gone until the project judges restoring it safe . That trade-off is the point: the exposed API surface was what made a leaked bearer credential remotely usable in the first place.

The Greenfield API fix bundled into the same release is a separate defect, not a second symptom of the macaroon flaw. Reported by @brunoerg and @benthecarman of the Bitcoin Red Team, it allowed a TOTP two-factor check to be bypassed through Basic authentication; the release notes treat the two issues independently . Disabling Basic auth by default five minutes after account creation narrows the window in which a long-lived password-style credential can substitute for a second factor.

On the disclosure side, the BTCPay Server Foundation donated 0.21 BTC each to Sparrow Wallet developer Craig Raw and to the Bitcoin Red Team fund, paying for the private heads-up that let the patch ship alongside the advisory rather than after it . The team behind the report also included Rob Hamilton, Calle, and ZEUS developer Evan Kaloudis . BTCPay tied the wave of findings to cheaper machine-assisted auditing, noting that "AI is changing the balance between attackers and defenders. As models improve, it becomes faster and cheaper to inspect large codebases" . What the timeline still lacks is accounting: BTCPay has not published how many operators were compromised or the aggregate sum stolen, with both figures deferred to a forthcoming postmortem .

This Isn't BTCPay's First Lightning Fund-Loss Incident

BTCPay Server operators have lost Lightning funds before, and the earlier episode failed in a completely different place. In December 2023, the compromise ran through LNbank — a third-party BTCPay plugin that let an administrator act as custodian for Lightning sub-accounts on their own instance — not through BTCPay core . Its maintainer, Dennis Reimann (d11n), noted that BTCPay plugins can be built and published outside the core team's review process . Two incidents, two years apart, both ending in swept Lightning channels — that pattern is structural, not coincidental.

The 2023 bug was a race condition, not a credential leak. Attackers issued multiple concurrent Lightning withdrawals before earlier withdrawals had been committed to the database, so each balance check read stale state — allowing repeated withdrawals beyond the actual wallet balance until the administrator's node was drained . Reports reached BTCPay's Mattermost and Telegram channels between the evening of Thursday, December 7 and the morning of Friday, December 8, 2023, and user logs showed active exploitation in progress . Servers with public registration enabled were the most exposed .

The most-cited single loss came from Hugo Ramos, running BTCPay Server 1.11.1 with LNbank 1.6.2, who reported that on December 6, 2023, 998 Lightning payments were routed to the same LN wallet path, draining 407,361,805 sats — roughly 4.07 BTC . A later independent security write-up summarized the same concurrent-withdrawal race and arrived at the same impact figure . Attacker identity, recoverability, and whether other victims stayed silent were never resolved — the same accounting gap the 2026 postmortem has yet to close.

From patch to deprecation: the LNbank timeline

The second critical issue, disclosed December 26, 2023, affected plugin v1.9.0; the fix in v1.9.2 both patched the bug and fully disabled sending as a loss-prevention measure, and the developer confirmed 1.9.2 would be LNbank's final release . BTCPay eventually removed the dependency outright: version 2.4.0, released June 25, 2026, dropped support for LNbank and Lightning Charge backends and moved LND from v0.19.3-beta to v0.21.0-beta, Core Lightning from v25.05 to v26.06.1, and phoenixd from 0.6.3 to 0.8.0 .

Not every BTCPay flaw has ended in stolen coins. CVE-2022-32984 affected public POS apps in versions 1.3.0 through 1.5.3 and was patched in v1.5.4 on May 28, 2022, disclosed without any report of exploitation in the wild . The distinction matters for reading risk: the two incidents that actually cost merchants money — 2023 and 2026 — both involved a component holding live Lightning credentials or custody, which is precisely where BTCPay's own documentation warns funds are at risk by design, since internal Lightning nodes run on hot wallets and balances should be kept low .

For anyone who ran LNbank in that era, the cleanup is still owed: treat old deployments as unsafe, remove the plugin, upgrade BTCPay and its Lightning components, and audit registrations, API activity, and withdrawals around December 2023 if the instance ever ran a vulnerable version .

The Bigger Risk Picture for Self-Hosted Lightning

Self-hosted Lightning infrastructure is carrying a systemic code-audit debt, not a one-off bug. The Bitcoin Red Team — the group that privately disclosed the macaroon flaw to BTCPay ahead of publication — has flagged 85 critical bugs across Bitcoin projects out of thousands of findings spanning hundreds of repositories . That ratio reframes the August 2026 sweep: it was one disclosure surfacing from a much larger backlog of unreviewed code that merchants, payment processors, and node runners already depend on.

The financial scale of that backlog is visible elsewhere in the same period. A separate Coldcard-related exploit accounted for roughly $116 million in confirmed losses across Bitcoin hardware and infrastructure . BTCPay has not yet published how many of its own operators were compromised or the aggregate amount swept; both figures are expected in a forthcoming postmortem . Until that lands, the honest read is that the visible losses in self-hosted Bitcoin tooling are a floor, not a total.

BTCPay itself framed the wave of findings around a shift in who can read code at scale:

"AI is changing the balance between attackers and defenders. As models improve, it becomes faster and cheaper to inspect large codebases." — BTCPay Server Foundation (source: The Block, 2026-08)

That cuts both ways, and the incentive structure around this disclosure shows why the defensive side needs funding to keep pace. The BTCPay Server Foundation donated 0.21 BTC each to Sparrow Wallet developer Craig Raw and to the Bitcoin Red Team fund for responsible disclosure, and on August 10, 2026 supporters announced a recovery bounty of 10% of any recovered funds, capped at 3 BTC . Cheap automated review means dormant bugs in long-lived repositories get found faster — by whoever is looking hardest. For an operator, the practical implication is that a self-hosted stack that was quiet for three years is not thereby safe; it is unaudited.

What this episode is not, so far, is a price event. Spot bitcoin markets largely shrugged off the disclosure, with the exploit unfolding against a broadly steady tape rather than a liquidation cascade (video: FatheryFinds). The exposure here is concentrated and operational: it lands on merchants, zines, hardware vendors, and node runners holding channel liquidity in hot wallets, not on holders of spot BTC. Treat it as infrastructure-trust risk to be managed at the deployment layer — patch cadence, credential rotation, balance caps — rather than a market signal to trade.

The reasonable planning assumption for the next 12 months is more disclosures of this shape, not fewer: mature codebases, credential-handling paths, and optional plugins reviewed at machine speed for the first time. Operators who size their Lightning balances on the assumption that the next critical bug is already written — just not yet found — will absorb the next one without a postmortem of their own.

What Lightning Node Operators Should Do Now

Every operator running BTCPay Server with an LND backend should treat their node as credential-compromised until proven otherwise, and work through a fixed sequence: update to 2.4.2 or later , regenerate macaroons and macaroons.db, rotate credentials on any independently exposed LND instance, and audit channel history. Patching alone leaves stolen bearer tokens valid . The order matters more than the speed.

The immediate checklist, in the order BTCPay published it:

• Update first. Server Settings → Maintenance → Update. Standard Docker deployments move to LND 0.21.1 and regenerate macaroon credentials automatically; integrators should also move to NBXplorer 2.6.10 .
• Regenerate credentials manually if you manage your own exposure. If LND is reachable through your own reverse proxy, a self-managed Tor hidden service, or a forwarded port, the BTCPay update does not close a route it does not manage — destroy and reissue macaroons and macaroons.db yourself, and rotate authentication strings for any other Lightning backend .
• Recreate any BTCPay-generated hot on-chain wallet. Move the funds out and generate a new wallet rather than reusing the old keys .
• Audit, then keep auditing. Look for unauthorized payments, unexpected or force-closed channels, unfamiliar peers, and any gap between your internal records and on-chain or Lightning balances .
• If you cannot update now, take the server offline. That was the project's explicit fallback instruction, not a cautious suggestion .

Beyond the incident response, BTCPay's standing documentation sets the balance policy: internal Lightning nodes use hot wallets for channel funds by design, off-chain funds need dedicated operational care, custodial Lightning services require trust in a third party, and channel balances should be kept low . For a merchant, that translates into a working rule: hold in channels only what you need to clear a few days of payment flow, and sweep the rest to cold storage on a schedule you actually keep. Foundation's node was drained overnight while its hot wallet stayed untouched — the separation of funds decided the size of the loss, not the speed of the response.

Two constraints remain in force. Remote LND API access over BTCPay domains and onion addresses stays switched off on Docker deployments, so external wallet connections — Zeus being the most commonly cited — will not reconnect until the project judges restoration safe; Lightning payments themselves keep working . And the two numbers this story still owes — how many operators were compromised, and how much bitcoin was taken in total — are due in BTCPay's forthcoming postmortem . Until those figures land, treat the incident's blast radius as unknown rather than small; commentary noting that spot markets shrugged it off is a statement about price, not about how many nodes were emptied (video: FatheryFinds).

The concrete takeaway: patch today, reissue every macaroon today, and set a channel balance ceiling you can afford to lose entirely. A recovery bounty of 10% of recovered funds capped at 3 BTC is on the table , but recovery bounties are a tail hedge, not a plan. The plan is a smaller balance on a rotated credential.

Frequently asked questions

Is my BTCPay Server node still at risk after updating to v2.4.2?

Yes, if you have not regenerated your credentials. Installing v2.4.2 closes the path that let an unauthenticated remote attacker retrieve .macaroon files, but it does not invalidate macaroons an attacker already copied — those stay valid bearer credentials until they are destroyed and reissued . The required sequence is: update via Server Settings → Maintenance → Update, regenerate macaroons and macaroons.db, rotate authentication strings for any other Lightning backend, and move funds out of any hot on-chain wallet generated inside BTCPay before recreating it . Standard Docker deployments are upgraded to LND 0.21.1 with automatic macaroon regeneration, and integrators were told to move to NBXplorer 2.6.10 . If you expose LND yourself — your own reverse proxy, a self-managed Tor hidden service, or a forwarded port — the BTCPay update does not close routes it does not manage, so you must rotate manually .

Does this exploit affect BTCPay deployments that don't use LND?

The credential-theft vector is specific to deployments using LND as the Lightning backend. Other Lightning implementations and on-chain-only BTCPay installations are not exposed through this particular path, though the project urged every operator to update regardless . Two reasons that advice applies broadly: every release prior to 2.4.2 is affected, including the 2.4.2 release candidates, and the same release fixed a separate TOTP two-factor bypass in the Greenfield API via Basic authentication (#7491), which is not backend-specific — Basic auth is now disabled by default five minutes after account creation . Note also that BTCPay's own on-chain wallets, including hot wallets, were not directly compromised by the macaroon leak, but bitcoin held in LND's internal on-chain wallet sits behind the compromised node and was therefore at risk .

How much was stolen in the August 2026 BTCPay exploit?

No aggregate figure has been published. BTCPay has not disclosed how many operators were compromised or the total amount taken; both numbers are expected in a forthcoming postmortem . Two victims are named on the record: Foundation, maker of the Passport hardware wallet, whose CEO Zach Herbert said the company's Lightning node was drained overnight with channels force-closed and funds swept while its hot wallet was untouched, and Citadel21, a Bitcoin zine that confirmed its node was swept but said it held minimal funds there . For contrast, the 2023 LNbank incident has a disclosed single-victim figure: Hugo Ramos reported 998 Lightning payments to the same wallet path on December 6, 2023, draining 407,361,805 sats — about 4.07 BTC . Treat any circulating total for August 2026 as unverified until the postmortem lands.

What's the difference between this exploit and the 2023 LNbank incident?

Different layer, different bug class. The December 2023 event ran through LNbank, a third-party BTCPay Server plugin that let an administrator act as custodian for Lightning sub-accounts; its maintainer, Dennis Reimann, noted that BTCPay plugins can be built and published outside the core team's review process . The mechanism was a concurrency race: attackers issued multiple simultaneous withdrawals before earlier ones were committed to the database, so each balance check read stale state and the wallet could be overdrawn repeatedly . Public alerts at the time stressed that BTCPay Server core was unaffected . The August 2026 flaw is the opposite: a core-side credential-exposure issue in how LND macaroon files could be retrieved without authentication . The plugin path is also closed — version 2.4.0, released June 25, 2026, dropped LNbank and Lightning Charge backends entirely and moved LND from v0.19.3-beta to v0.21.0-beta .

Can I get my funds back if my node was drained?

There is one active mechanism, and it is not a guarantee of return. On August 10, 2026, BTCPay Server supporters announced a recovery bounty of 10% of any recovered funds, capped at 3 BTC, to incentivize tracing and the return of stolen bitcoin . Swept Lightning channel funds are otherwise irreversible once force-closed and moved on-chain, so the practical steps are documentation and containment rather than clawback: audit for unauthorized payments, unexpected channel closures, unfamiliar peers, and gaps between internal records and on-chain or Lightning balances . Separately, the same disclosure process was rewarded upstream — the Foundation donated 0.21 BTC each to Sparrow Wallet developer Craig Raw and to the Bitcoin Red Team fund . Plan around the assumption that channel balances lost to a credential compromise stay lost.

Watch / Sources

• FatheryFinds — Bitcoin at $65K While Lightning Nodes Drained: The Real Risk Revealed

Last updated: 2026-08-12. Reviewed against BTCPay Server's v2.4.2 security advisory and release notes, plus contemporaneous reporting through August 10, 2026; aggregate loss figures remain pending the project's postmortem.

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

Subscribe