The Patch Is Not the Fix: BTCPay's Leaked Macaroons Keep Working After You Update

What Happened

On Friday, August 7, BTCPay Server, the open source payment processor that thousands of merchants and individuals run to accept Bitcoin without an intermediary, posted an urgent alert: a critical vulnerability was under active exploitation, and operators needed to update to version 2.

4.2 immediately and confirm the new version number in the server footer. The flaw allowed an unauthenticated remote attacker to retrieve .macaroon files, the credentials that authorize software to perform actions on an LND (Lightning Network Daemon) node. With sufficiently privileged credentials in hand, an attacker does not need to break anything else: the node treats whoever presents them as the operator.

The project told administrators who could not patch immediately to turn their servers off until they could, and credited security researchers with reporting the bug, which Decrypt identified as members of Bitcoin Red Team.

The warning arrived after the draining had already started. Zach Herbert, co-founder and CEO of hardware wallet maker Foundation, reported that the company's Lightning node was emptied overnight: attackers force-closed its payment channels and transferred out the available funds, while its separate on-chain wallet was untouched.

Citadel21, the Bitcoin zine run by the pseudonymous writer hodlonaut, said its node was swept as well, though it held little at the time. As of this writing, BTCPay Server has not disclosed how the flaw works, when exploitation began, how many servers were hit, or a total loss figure.

What is established is narrower: the attacks the project reviewed targeted LND credential files, and the confirmed damage was to Lightning balances, not to the on-chain wallets most operators use for settlement.

The server you run so nobody else touches your money spent Friday serving up its own keys. Update it, then change the locks: the patch closes the door, but only new credentials evict whoever already copied the key.

A Macaroon Is a Bearer Key, and the Patch Does Not Change the Locks

Macaroons are LND's permission system: bearer credentials that work like scoped API (application programming interface) keys. A read-only macaroon can observe the node, an invoice macaroon can create payment requests, and the admin macaroon can do anything, including sending funds.

Bearer means possession is proof: whoever presents the file gets the access it encodes, from anywhere, with no further authentication. BTCPay Server sits in front of LND precisely so that a storefront can talk to the node, which means it holds those credentials. The vulnerability turned that convenience inside out: the component trusted to guard the node's keys became the channel that served them to strangers.

The detail that separates this incident from an ordinary patch cycle is persistence. Updating to 2.4.2 closes the leak, but it does not invalidate any credential copied before the patch landed. BTCPay's own checklist makes the point: after updating, operators must regenerate their macaroon files and the macaroons.

db database, refresh authentication strings for any other Lightning backend they have connected, and move funds out of any hot on-chain wallet generated inside BTCPay before recreating it. An operator who updates and stops there has locked the door while the copied key still works.

The parallel to the past 2 weeks is uncomfortable: the Coldcard firmware patch could not repair already-weak seeds, the CryptoJS fix could not strengthen already-generated recovery phrases, and this patch cannot revoke already-stolen macaroons. In all 3 cases the fix ships in software, but the exposure lives in artifacts the fix does not touch.

3 Weeks, 3 Failures in the Self-Custody Supply Chain

The BTCPay exploit is the 3rd Bitcoin infrastructure failure in roughly 2 weeks, after the Coldcard firmware randomness flaw (measured at $116 million and 1,816 BTC by TRM Labs) and the Ill Bloom wallet drains traced to a weak CryptoJS random function (a $5.7 million lower bound).

None of these touched the Bitcoin protocol. Consensus, mining, and the base layer performed exactly as designed. Every failure sat in the surrounding equipment that people adopt in order to hold their own keys: a hardware wallet's firmware, a JavaScript library inside wallet apps, and now the payment server that connects a store to a Lightning node.

That is what makes this a Trust Inversion story: each layer exists to protect users from custodians and intermediaries, and each briefly became the attack surface itself.

The obvious counter-argument deserves a straight answer: does a month like this prove that self-hosting is a mistake and custodians are safer? The math does not support it. Custodial failure concentrates everything in one place: a single exchange breach, Bybit's $1.5 billion loss in February 2025, cost more than 10 times these 3 incidents combined, and a custodian failure takes every customer at once while adding the freeze and seizure exposure that holding your own keys does not carry.

What this month actually demonstrates is the value of tiering. Foundation lost a Lightning node's channel balances, not its treasury. Citadel21 lost almost nothing because it kept almost nothing hot. In both cases the blast radius was set in advance by a decision about how much value lives in internet-connected infrastructure.

Self-custody did not fail these operators; their tiering held.

What This Means for You

If you run BTCPay Server with an LND node, the sequence is specific and ordered. Update to 2.4.2 and confirm the version number in the server footer. If you cannot update today, take the server offline: an unpatched, reachable server is the exposed condition. Then rotate credentials: regenerate the macaroon files and the macaroons.

db database, refresh authentication for any other Lightning backend, and if you generated a hot on-chain wallet inside BTCPay, move those funds and recreate the wallet. The patch without the rotation is half a fix.

Operate on the assumption of compromise rather than the hope of luck. If your server ran an affected version while connected to LND, treat the credentials as copied: check your node for channel force-closes you did not initiate, audit recent transactions, and rotate even if nothing looks wrong. A copied macaroon costs an attacker nothing to hold quietly and use later.

The structural lesson applies whether or not you run this particular software. A Lightning node is a hot wallet by design: its private keys sit on an internet-connected machine, which is what lets it route payments in real time. Money that lives there is spending-tier money. Savings belong in cold storage, on a hardware wallet whose keys never touch the server, ideally behind multi-sig, with no credential path from your payment infrastructure to your reserves.

And self-custody carries an operational duty that this week made explicit: if you run the infrastructure, you are the security team. Subscribe to the release channels of every component you operate, and treat anything rated critical as a same-day patch, not a weekend project.

What to Watch

The unanswered questions are BTCPay's to answer: a post-mortem naming the root cause, the date exploitation began, and how many servers were compromised. A loss total may emerge from chain analysis even without the project's help, since forced channel closures leave visible on-chain footprints.

Watch for a slow tail of drains in the coming weeks against operators who patched but never rotated credentials, which is the signature this credential-persistence problem would leave. And watch whether 3 infrastructure failures in a month push the ecosystem toward funding audits for the short list of tools (wallet firmware, cryptography libraries, payment servers) that the entire self-custody economy leans on.

Tracked entities this report names, with total coverage across the archive. Follow one into the Actor Network to see every report it appears in.

Other reports that name the same tracked actors — a different thread than “related,” which follows wording. These are linked by who appears in them.