# BTCPay Server Patches Flaw That Let Attackers Take Lightning Node Credentials From Merchants

Stolen macaroon files stay valid after the update, so operators who patch without regenerating credentials remain exposed, and the bug was found only after a wallet developer lost money and read his logs.

- Published: 2026-08-09T06:30:14.346Z
- Canonical: https://polylog.news/crypto/2026-08-09/btcpay-server-patches-flaw-that-let-attackers-take-lightning
- Publisher: Polylog (Crypto desk)
- Section: crypto
- Sources: [CoinDesk](https://www.coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes), [Bitcointalk Dev & Technical](https://bitcointalk.org/index.php?topic=5590329.20), [Rekt News](https://www.rekt.news/)

BTCPay Server, the self-hosted payment processor used by bitcoin merchants who do not want a third party holding their funds, [confirmed an actively exploited vulnerability](https://www.coindesk.com/tech/2026/08/08/another-bitcoin-infrastructure-exploit-hits-this-time-draining-merchant-lightning-nodes) and released version 2.4.2. The flaw allowed an unauthenticated remote attacker to retrieve the macaroon files that authorise commands to Lightning Network Daemon (LND), the most widely deployed Lightning implementation. Possession of those files is equivalent to control of the node.

Attackers used that control to force channels closed and move funds out. Hardware wallet maker Foundation and the bitcoin publication Citadel21 both reported that their nodes were emptied. The [attack vector was credential theft rather than a cryptographic break](https://en.cryptonomist.ch/2026/08/08/btcpay-server-vulnerability/), which matters for the remediation: patching the server closes the path used to steal the files, but any macaroon already copied remains valid until the operator deletes and regenerates it. BTCPay told operators who cannot patch immediately to take their servers offline.

The discovery route is the part practitioners are discussing. BTCPay founder Nicolas Dorier said the bug surfaced because Craig Raw, the developer of Sparrow Wallet, lost funds and then analysed his server logs. It was not caught by an audit or by automated code review. That sits awkwardly beside the argument, common through 2026, that machine-assisted analysis is now closing the gap between attackers and defenders on open-source infrastructure.

For a payment stack marketed on the premise that merchants should not rely on a custodian, the incident points at a different dependency. Self-hosting removes the custodian and replaces it with the merchant's own server administration. Anyone running a web-facing node inherits the full burden of patch discipline, credential rotation and log review, and the incident catalogue maintained by [Rekt News](https://www.rekt.news/) has filled through 2026 with losses that originated at that layer rather than inside a smart contract.

## What this means

The loss channel here is operational, not monetary policy or market structure: merchants running their own Lightning nodes are the exposed party, and their working capital sits in hot channels that cannot be air-gapped because payments must clear instantly. Every incident of this type raises the practical cost of self-hosted bitcoin payments relative to a custodial processor, which pushes small merchants toward intermediaries and slowly concentrates Lightning liquidity in professional routing nodes. That is the opposite of what the payment layer was designed to produce.

## What to watch

- Whether BTCPay publishes a count of affected instances and a total loss figure, which would show whether this hit a handful of nodes or a meaningful share of merchant capacity.
- Whether LND and competing implementations move to short-lived or scoped credentials by default, since permanent all-powerful macaroons are the reason a single file read becomes a total loss.
- Whether merchant-facing processors report a shift in signups toward custodial Lightning services in the weeks after the disclosure.