BTCPay: the audit ended on August 5 and nodes were falling by the 7th

On August 5, 2026, the largest security audit in the history of the Bitcoin ecosystem concluded with 4,962 findings in 27.5 hours; on the night of the 6th to the 7th, a flaw not listed in that report began draining Lightning nodes via BTCPay Server. BTCPay is the self-hosted payment processor used by merchants and projects to accept Bitcoin without intermediaries, and the flaw allowed a remote attacker, without any authentication, to download .macaroon files — the administrative credentials for LND (the most widely used Lightning node implementation). With this file, attackers force-closed channels and swept funds from high-profile victims: Foundation, the manufacturer of the Passport hardware wallet; Citadel21, hodlonaut's publication; and Sparrow Wallet developer Craig Raw himself, who reconstructed the attack from his server logs after losing funds. Patch 2.4.2, released on August 7, closes the entry point, but already stolen credentials remain functional until rotated. This article establishes the timeline from August 4 to 10, the macaroon mechanism, what the AI-assisted sweep missed, and the steps the advisory demands beyond simply updating.

What happened with BTCPay Server between August 4 and 10, 2026?

Seventy-two hours separate the start of the Bitcoin Red Team sweep (afternoon of August 4) from the formal BTCPay advisory (August 7). In between lie the conclusion of the audit, the first drained nodes, the emergency alert, and the public admission that the AI-assisted report did not contain the flaw being exploited. The sequence, cross-referenced against the official advisory, The Defiant, The Block, and Crypto Briefing, is as follows:

Two details of the timeline carry more weight than the rest. First: the exploitation was already underway when the alert was issued — Foundation and Citadel21 lost funds before they could read anything. Second: the most massive audit the ecosystem has ever received and the live exploit crossed paths in the same week, on the same stack, without touching.

Why does a BTCPay .macaroon file give total control of the Lightning node?

A macaroon is the LND API credential: a bearer token, comparable to an administrative session cookie that never expires. The node does not check who presents the file; it checks that the file is valid. LND issues several macaroons with tiered permissions — read-only, invoice, administrative — and BTCPay needs to store them on the server to communicate with the node: that was the file the flaw left within anyone's reach. The administrative one authorizes all operations — opening and closing channels, signing, and moving funds — without additional passwords or second-factor authentication. This is why the August 7 advisory summarizes the flaw in a single sentence: the vulnerability allowed "an unauthenticated remote attacker to obtain LND .macaroon credential files."

This design also explains why remediation requires a manual step. Macaroons descend from a root key stored by the node itself; as long as that key is not regenerated, any copy of the file — wherever it may be — remains valid for authentication. Rotating them means invalidating the previous issuance and regenerating the files, then reconfiguring every application connected to the node. The patch automates this rotation in standard deployments, but it cannot know how many copies of the file were leaked or where — reviewing history remains the responsibility of the operator.

The technical details of the vector have not been published. The advisory does not assign a CVE or GHSA as of August 20, 2026, and The Defiant notes that the exploited flaw does not match what is visible in the changelog: on August 4, BTCPay had fixed a two-factor authentication bypass in its Greenfield API (the validator only checked FIDO2 keys, allowing email and password through on accounts protected by authenticator apps), a different issue from the one that drained the nodes.

The scope is defined: all versions prior to 2.4.2, including release candidates of 2.4.2 itself, and only in deployments connected to LND. BTCPay on-chain wallets, including hot wallets, are unaffected — although the project itself took time to confirm this: the initial guide advised moving all funds, and the advisory update narrowed it down after reviewing the case ("we confirm that only LND is impacted").

Who lost funds to the BTCPay exploit and how much was stolen in total?

Three victims have come forward with public statements. Zach Herbert, CEO of Foundation, posted on August 7 that the company's Lightning node had been "drained overnight," with channels force-closed and funds swept; his BTCPay on-chain hot wallet remained intact, consistent with the scope of the flaw. hodlonaut issued a live warning — "this is an ongoing attack against BTCPay Server users; the Citadel21 Lightning node just got swept" — clarifying that the node held a small balance. And Craig Raw, developer of Sparrow Wallet, lost funds from his own node and used his server logs to reconstruct the vector; BTCPay credits him for responsible disclosure in the advisory. Dorier summarized it bluntly: "we were very lucky that the person affected was a developer capable of analyzing the logs and understanding what was happening."

Disclosure was deliberately fast. According to TFTC's reconstruction, the team that analyzed the flaw compressed the usual responsible disclosure timeline with an explicit argument: "others will find the same flaws." With exploitation already in progress, every additional hour of silence worked for the attacker, and the alert and patch were released the same morning of August 7 — with instructions to shut down the server as a bridge measure for those who could not wait.

The total amount stolen has not been made public. BTCPay has not published the number of compromised servers or the total Bitcoin drained, and none of the victims have put a figure on their loss as of August 20, 2026. There is also no denominator: BTCPay is self-hosted software without a central registry of deployments, so there is no public census of how many instances run LND or what fraction was exposed. Any global figure circulating in mid-August 2026 is an estimate without a verifiable basis.

What does BTCPay 2.4.2 fix on its own and what remains for the operator?

The patch fixes the code that exposed the files and, in standard Docker deployments, does two more things: it automatically regenerates macaroons by upgrading LND to 0.21.1 and temporarily removes public access to the LND API — an external wallet like Zeus can no longer connect via the domain or onion address until the project deems it safe to restore. What no patch can do is reach nodes that remain on previous versions: there, the macaroon stolen on August 7 opens the node just as well on the 20th, because the credential lives in LND until it is regenerated. The advisory mandates the full sequence:

1. Update to BTCPay Server 2.4.2 with LND 0.21.1 (in standard Docker, the update regenerates macaroons automatically).
2. In manual or non-standard installations, rotate macaroons manually.
3. Review node activity for unauthorized channel closures and transactions.
4. Shut down the server if the update cannot be immediate.

This is the second time in the same month that an ecosystem patch has arrived with this fine print. The Coldcard entropy flaw, fixed via firmware in early August, left already generated weak seeds intact: updating the device does not repair the keys it produced. In BTCPay, updating the server does not invalidate the credentials that left it. In Coldcard, the corrected firmware does not repair already generated seeds. In BTCPay, 2.4.2 does regenerate macaroons for standard deployments; what nothing updates are the nodes that remain on vulnerable versions, where the prior damage remains operational.

What did the Bitcoin Red Team audit find and what did it miss in BTCPay?

The Bitcoin Red Team is a group of volunteers — 16 researchers, according to The Defiant — who between August 4 and 5 pointed AI-assisted analysis tools at 390 open-source projects in the Bitcoin stack, with approximately $40,000 in funding from OpenSats and a proprietary harness of 171,599 lines of code that doesn't just flag findings: it tests, reproduces, and documents them. The result, 4,962 findings in 27.5 hours with 85 critical, is the largest security sweep the ecosystem has ever received, mounted as a reaction to the Coldcard case from the previous week. The group has announced it will open-source its tools and offer the harness to audit closed-source implementations as well, turning the August 4-5 experiment into the first edition of a recurring program.

The BTCPay flaw was not in that report. Nicolas Dorier himself said so on X on August 7, with the exploit still active: "The AI report we got from red team didn't include this one. But this bug was really sneaky, I am not surprised a simple scan didn't find it, or thought it was low risk."

It is worth reading this data in its exact context. It is a sample size of one: a false negative does not invalidate a methodology that produced 85 verifiable critical findings in 27.5 hours, just as a success would not consecrate it. What it does document, with a specific date and case, is which layer scale-scanning performs worst at: application logic errors — who can request which file under what condition — that a static analysis might classify as low-risk noise. The outcome itself highlights the complementarity between layers: the same Red Team whose report did not list the flaw handled the coordinated disclosure and exploit analysis alongside BTCPay, receiving 0.21 BTC from the project for it. The gap between what AI detects and what gets patched has its own figures; the BTCPay case documents the first massive audit with a false negative dated and exploited days later.

Is the BTCPay exploit the first Bitcoin case of the perimeter thesis?

In June, we documented that major 2026 thefts no longer attack the contract but the perimeter: credentials, deployment infrastructure, developer tools. The entire universe of that taxonomy was DeFi on EVM. BTCPay extends it to the Bitcoin stack with a textbook case: the attacker did not break cryptography, did not exploit a Lightning or LND flaw, and did not touch the protocol. They stole a file from a payment server and operated the node as its legitimate administrator.

The uncomfortable detail is that Lightning worked exactly as designed. Force-closing channels is a planned protocol operation, available to whoever presents the administrative credential; funds left via valid transactions signed by the victim's node. Just as in the EVM cases from June, the perimeter — an accessible file where it shouldn't have been — rendered all the cryptographic security of the lower layers irrelevant, because the attacker entered above it. For the threat model of those who self-host Bitcoin payments, the case reorders priorities: the surface to monitor includes every piece of the server that stores or serves node credentials, and the stakes are not small — the project's own 2025 annual report boasts individual processed payments of up to $2 million, such as Namecheap's.

How does BTCPay fit into the August of Bitcoin custody?

The BTCPay exploit is the third distinct vector to fail in the same month, and none of the three is the protocol. August 2026 leaves behind a device flaw (Coldcard's weak entropy), a data breach at Trezor's logistics provider exploited for targeted phishing, and now exposed infrastructure credentials on a self-hosted payment server. Each case has a different remedy — regenerating seeds, distrusting post-sale emails, rotating macaroons — and all three share the attacker's economics: compromising the operational link surrounding the keys costs orders of magnitude less than attacking the cryptography that protects them. The table summarizes what failed and what remained intact in each case:

The market's reaction to this series already has its own metric: after Coldcard, Bitcoin's share in ETF flows barely moved from 67.7% to 71.2%, with no sign of a flight from self-custody. The BTCPay case does not alter that reading either: it hits a very specific profile — operators who self-host payments with their own Lightning node — and leaves out the average Bitcoin holder, with a total amount that isn't even public.

What should a BTCPay operator with LND do after the exploit?

The BTCPay Server version is visible in the footer of the instance itself: if it is prior to 2.4.2, the advisory's order remains in effect — update immediately or shut down. With the server already on 2.4.2 and LND on 0.21.1, the steps the patch does not perform automatically remain: review the node's history for channel closures and unrecognized transactions, and rotate macaroons. Rotation is worth doing even if there are no signs of intrusion: Foundation's logs prove that the sweep preceded the public alert, so the absence of warnings during those days does not guarantee the absence of credential copying.

The node review has specific signs to look for. A force-close leaves a double trail: it appears in LND's own channel history and is written to the chain as a unilateral closing transaction, so an operator can audit whether they initiated all closures in the first week of August. Any unrecognized closure, outgoing payment without an associated invoice, or off-hours API connection in the server logs makes macaroon rotation urgent and justifies moving the remaining balance to a node with clean credentials.

For funds already stolen, a path has been open since August 10: project supporters are offering 10% of recovered funds as a bounty, capped at 3 BTC for full recovery, as reported by The Block. As of August 20, no recoveries have been made public. What has been paid is the other bill from the incident: 0.42 BTC from BTCPay to those who responsibly disclosed and analyzed the flaw — half to the developer who found it by reading his own logs after losing money, the other half to the team — of which Raw himself is a member — whose scanner, two days earlier, had passed over it without seeing it.

Sources and links: Official BTCPay Server 2.4.2 Advisory (August 7-10, 2026) · The Defiant · The Block — recovery bounty · Crypto Briefing — Bitcoin Red Team findings · TFTC · CoinDesk