BTCPay Server v2.4.2 Patches Live LND Macaroon Exploit Draining Lightning Nodes

A critical BTCPay Server vulnerability let unauthenticated attackers steal LND macaroon credentials and drain Lightning channels. Foundation and Citadel21 were hit before the public alert went out. Update to v2.4.2 immediately, then revoke macaroons and move hot wallet funds.

TFTC Newsdesk

August 8, 20264 min read

A close-up of tangled ethernet cables plugged into a compact black server rack mounted on a raw concrete wall, bathed in the cold blue glow of blinking indicator lights, with a single red

Attackers stole LND credentials from live BTCPay deployments and swept Lightning channels before the public alert went out. Patching alone does not close the door.

Key takeaways

BTCPay Server v2.4.2 patches a critical, actively exploited vulnerability that allowed unauthenticated attackers to steal LND .macaroon credential files and drain Lightning node channels.
Updating to v2.4.2 stops new access but does not invalidate credentials already stolen. Operators must also revoke LND macaroons and move funds from any BTCPay-generated on-chain hot wallet.
Foundation (Passport hardware wallets) and Citadel21 confirmed their Lightning nodes were swept before BTCPay's public warning went live, underscoring how little time operators have between responsible disclosure and active exploitation.

BTCPay Server confirmed on August 7, 2026 that a critical vulnerability was being actively exploited against live servers, allowing unauthenticated remote attackers to steal .macaroon files and drain Lightning node channels. The team released v2.4.2 immediately and told anyone running LND behind BTCPay to update now or take the server offline.

The official warning was direct: "There is a critical vulnerability being actively exploited on BTCPay Server, which can result in the loss of funds." The release notes from founder Nicolas Dorier reinforced it: "This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can."

What the Exploit Actually Did

.macaroon files are credential tokens that grant software permission to interact with an LND Lightning node. Whoever holds them controls the node. The BTCPay flaw let an unauthenticated attacker retrieve those files remotely, without any login or access credential. From there, taking control of the node and sweeping its channels was straightforward.

BTCPay's standard on-chain wallets are not directly affected by the credential flaw. The exposure is specific to deployments using LND. However, funds held in LND's own on-chain wallet are at risk, because that wallet sits under the compromised node.

Foundation, the company behind the Passport hardware wallet, had its BTCPay Lightning node drained overnight. CEO Zach Herbert confirmed attackers closed the company's channels and swept the funds. Its BTCPay on-chain hot wallet was untouched. Citadel21, the bitcoin publication associated with pseudonymous commentator hodlonaut, also reported its Lightning node was swept, noting little money was held there.

The Bitcoin Red Team, which has been pointing tooling at bitcoin codebases and filing findings across hundreds of repositories, disclosed the vulnerability to BTCPay before it went public. Credited members include Craig Raw (Sparrow Wallet), Rob Hamilton, Calle, and Evan Kaloudis (ZEUS wallet). Their stated rationale for rapid disclosure: others will find the same bugs. By the time BTCPay's alert went out, the exploitation was already in progress.

BTCPay Server official security alert, @BtcpayServer, August 7, 2026

Patching Is Step One of Three

This is the part most operators will miss. Updating to v2.4.2 closes the door to new attackers. It does nothing to invalidate credentials already stolen from a previously exposed server.

Any operator whose server was running a vulnerable version must also: (1) revoke LND macaroons at the node level, which destroys the root signing key rather than simply deleting the files; and (2) move funds from any BTCPay-generated on-chain hot wallet and recreate it. BTCPay's own alert stated: "If you generated a hot on-chain wallet in BTCPay, you want to move those funds and recreate the wallet."

An operator who patches but skips those two steps remains compromised.

The remediation details are documented in the Start9Labs BTCPay packaging release. BTCPay has withheld full technical details of the vulnerability while patching is still in progress. A postmortem is forthcoming.

The Maintenance Cost of Sovereignty

This incident lands in the same week that the Boltz Bitcoin swap service suspended operations following AI-assisted attacks, and close to the Coldcard breach that shook long-term holder confidence in self-custody tooling.

The throughline is not that Bitcoin is broken. The protocol is fine. The throughline is that self-sovereign infrastructure carries a non-negotiable maintenance burden, and the window between responsible disclosure and live exploitation is now measured in hours, not weeks.

Foundation and Citadel21 were drained before the public alert went out. The Bitcoin Red Team's disclosure compressed the timeline because the alternative, sitting on the bug, hands the same window to less cooperative finders. That is the correct call. But it means operators who cannot respond to a critical patch notification within hours are running infrastructure they do not actually control.

BTCPay is one of the most important pieces of Bitcoin's merchant acceptance stack. If small operators conclude that running a self-hosted Lightning node carries too much operational risk, the pull is toward custodial Lightning solutions. That is the wrong direction.

The falsifiable version of that thesis: if BTCPay's postmortem reveals that patched, current-version servers were also compromised, the problem shifts from operator discipline to software trustworthiness regardless of discipline. That would be a materially different situation. Watch the postmortem.

What to Watch

BTCPay has not disclosed the number of servers hit or the total bitcoin drained. The postmortem, expected in the coming days, will carry the full technical breakdown of the flaw. According to reporting at cryptonomist, the separate TOTP/2FA bypass patched in the August 4 changelog is a distinct issue unrelated to the August 7 exploit; operators should verify this independently against BTCPay's own changelog as a full postmortem has not yet been published. Operators should verify they are running v2.4.2 (visible in the server footer), have completed full macaroon revocation, and have moved any hot wallet funds before considering the remediation complete.

Sources

BTCPay Server official security alert, @BtcpayServer, August 7, 2026
BTCPay Server v2.4.2 GitHub release
Start9Labs BTCPay packaging release (remediation detail)

Frequently Asked Questions

No. The update closes the vulnerability and prevents new credential theft. It does not invalidate macaroon files that were already stolen from a previously exposed server. Operators must separately revoke LND macaroons at the node level to destroy the root signing key and move any funds held in a BTCPay-generated on-chain hot wallet.

A macaroon is a credential token that grants permission to interact with an LND Lightning node. Think of it as an API key with defined access rights. Whoever holds the macaroon can instruct the node to open or close channels and move funds. The BTCPay vulnerability let attackers retrieve these files without any authentication, giving them full node control.

Not directly. The credential flaw targets LND-specific deployments. BTCPay's standard on-chain wallets are not affected by the macaroon theft itself.

However, funds held inside LND's own on-chain wallet are at risk because that wallet sits under the compromised node. Operators should review both their Lightning channel balances and any funds held within the LND node itself.