A file named 'macaroon' let hackers drain Bitcoin nodes

A credential file most Bitcoin merchants had never opened turned into the master key to their Lightning nodes. On August 7, 2026, BTCPay Server confirmed the theft was already underway .

What Happened to BTCPay Server, and Is It Still Dangerous?

BTCPay Server — the self-hosted, open-source Bitcoin payment processor — disclosed a critical, already-exploited vulnerability on Friday, August 7, 2026, and shipped version 2.4.2 the same day . The flaw let an unauthenticated remote attacker retrieve .macaroon files, the bearer-token API credentials used by LND (Lightning Network Daemon); an admin macaroon grants full node control, including opening and closing channels and moving funds. Every release before 2.4.2, including its release candidates, was affected .

Quick Answer: A BTCPay Server flaw disclosed August 7, 2026 let unauthenticated attackers steal LND .macaroon credentials and drain merchant Lightning nodes. Version 2.4.2 patches it, but stolen macaroons stay valid after updating — operators must rotate credentials separately. On-chain wallets were never exposed.

The project's own language was unusually direct: BTCPay confirmed that "attackers exploited this vulnerability. Users were affected and funds were stolen," and advised operators who could not patch immediately to take their servers offline entirely . Technical details were deliberately withheld at disclosure to give merchants a window to update. You can read the first-party notice on the BTCPay Server security advisory; a published GHSA or CVE entry had not appeared on the project's GitHub advisories tab as of research time, making the blog post the canonical disclosure surface.

Scope matters here, and it is narrower than early panic suggested. On-chain wallets, including BTCPay hot wallets, were not affected, and deployments running another Lightning implementation — or no Lightning at all — were never exposed to the macaroon risk . Initial guidance to move on-chain funds was precautionary and later walked back. Foundation CEO Zach Herbert, speaking on The Defiant, framed the defect as living in BTCPay's authentication flows rather than in the LND client itself (video: The Defiant).

"It was specific to BTCPay's authentication flows, not a defect in LND itself — the exposure was limited to Lightning node access, not the on-chain hot wallet," — Zach Herbert, CEO, Foundation (source: The Defiant)

Is it still dangerous? For unpatched servers, yes — and for patched ones, partially. A software update does not invalidate credential files an attacker already copied. Macaroons exfiltrated before August 7 remain valid bearer tokens until they are rotated, which is why the advisory instructs operators to regenerate macaroons and macaroons.db, refresh auth strings, and audit LND activity for unrecognized peers, unexpected channel closures, and payments they did not initiate . Integrators were separately told to update NBXplorer to 2.6.10 and LND to 0.21.1 . Treat the checklist below as the minimum triage:

• Update to 2.4.2 — release candidates of 2.4.2 are also vulnerable .
• Rotate macaroons and macaroons.db — updating via the maintenance dashboard regenerates them automatically.
• Audit node history for unknown peers, forced channel closures, and outbound payments you did not authorize.
• Confirm your exposure surface — no Lightning, or non-LND Lightning, means the macaroon path did not apply to you.

How the Macaroon Exploit Actually Worked

The exploit worked because BTCPay Server leaked LND's bearer credentials to anyone who asked. A macaroon is the authentication token format used by LND (Lightning Network Daemon), and an admin macaroon is a bearer credential: whoever holds the file can open and close channels and move funds without any further login, password, or second factor. The BTCPay advisory describes the flaw as allowing an unauthenticated remote attacker to obtain .macaroon files from an affected server . Once that file left the server, the attacker held the same rights as the merchant.

That distinction matters for scoping. Bearer tokens carry no identity check on presentation, so there is no login trail for an operator to spot, no failed-password counter to trip, and no session to revoke. The credential is the permission. This is also why the incident produced clean-looking node logs on the victim side: from LND's perspective, an authorized admin was issuing instructions.

Every BTCPay Server release before 2.4.2 was affected, and the advisory explicitly includes the 2.4.2 release candidates in the vulnerable set . Operators who had already pulled an RC to test the upcoming release were not ahead of the problem; only the final 2.4.2 build, shipped on Friday, August 7, 2026, closes it .

The defect sat in BTCPay's own authentication handling around its LND integration, not in LND. Foundation CEO Zach Herbert, speaking on The Defiant, characterized the issue as specific to BTCPay's authentication flows rather than a defect in the LND client itself, and said the exposure was limited to Lightning node access rather than the on-chain hot wallet (video: The Defiant).

"This was specific to BTCPay's authentication flows rather than a defect in the LND client itself — the exposure was limited to Lightning node access, not the on-chain hot wallet," — Zach Herbert, CEO at Foundation (source: The Defiant, 2026-08)

The published 2.4.2 release notes give the clearest public signal of where the authentication logic broke. Among the security fixes is a TOTP two-factor authentication bypass via Greenfield Basic authentication, accompanied by a breaking change that disables Basic authentication by default five minutes after account creation . Note the framing gap here: at least one outlet described the incident purely as a 2FA bypass, which is narrower than the advisory's own unauthenticated-disclosure language. The first-party advisory and release notes are the authoritative descriptions.

Alongside the patch, the project took a blunt architectural step: it pulled public remote access to the LND API on Docker deployments as an emergency hardening measure . That change removes the reachable surface rather than trusting the fixed code alone — a reasonable default, though it breaks setups that were deliberately exposing the LND API to external tooling. Integrators were also directed to update NBXplorer to 2.6.10 and LND to 0.21.1 . Deployments running no Lightning, or a non-LND Lightning implementation, had no macaroon files to leak and were outside this specific attack path .

Who Got Drained: Foundation, Citadel21, and the Sparrow Wallet Developer

The publicly named victims of the BTCPay Server macaroon exploit are Foundation, the company behind the Passport hardware wallet, and the Bitcoin publication Citadel21 . A third affected party was Craig Raw, the developer of Sparrow Wallet, whose own losses triggered the investigation that ultimately produced the disclosure . Beyond those three names, the picture stays deliberately incomplete: BTCPay Server has not published an aggregate figure for stolen funds or a count of compromised nodes across its wider merchant base.

Foundation's case is the most documented, and it illustrates why a Lightning-only exposure was still commercially painful. The company had run BTCPay Server for its online store since 2020, and its Lightning node was drained overnight on a Thursday, roughly a week and a half to two weeks into the broader Bitcoin security incident window . The timing landed badly. In the two weeks after the preceding Coldcard incident, roughly 40% of Foundation's sales had arrived over Lightning, at an average purchase price of about $400 — meaning the compromised rail was carrying a substantial share of live revenue at the moment it was breached (video: The Defiant).

The disclosure path itself is the part worth dwelling on. The vulnerability was not caught by a scheduled audit, a bug bounty submission, or automated monitoring. It surfaced because Raw lost funds, pulled his own node logs, worked backward through the activity, and reported what he found rather than staying quiet. BTCPay Server founder Nicolas Dorier has credited that sequence directly as the reason the bug came to light at all .

"Attackers exploited this vulnerability. Users were affected and funds were stolen." — BTCPay Server project advisory, August 7, 2026 (source: BTCPay Server, 2026-08)

Foundation CEO Zach Herbert, speaking about the incident afterward, framed the flaw as living in BTCPay's authentication flows rather than in the LND client itself, and confirmed his company's exposure was confined to Lightning node access — the on-chain hot wallet was untouched . That distinction matters for anyone assessing their own risk, but it offers limited comfort to merchants whose Lightning channels held working capital.

What remains unquantified is the tail. Self-hosted software has no telemetry by design, so BTCPay cannot easily enumerate who was running an exposed instance, and operators who lost small amounts have little incentive to publicize it . The three named victims should be read as the visible portion of the damage, not its full extent.

What BTCPay Server 2.4.2 Actually Fixes

BTCPay Server 2.4.2, released on August 7, 2026, closes the unauthenticated route that let a remote attacker retrieve LND .macaroon credential files, and it patches a second authentication defect in the same release . Every release before 2.4.2 is affected, including the 2.4.2 release candidates, so a server sitting on an RC build is not patched . The upgrade is the minimum step, not the complete one.

The second fix listed in the v2.4.2 release notes is a TOTP two-factor-authentication bypass via Greenfield Basic authentication — meaning an account protected by a time-based one-time code could be reached through the API's Basic auth path without that code being enforced . Note that at least one outlet described the whole incident as a 2FA bypass; the first-party advisory describes an unauthenticated macaroon disclosure, and that is the broader and authoritative framing .

The release also carries a breaking change that will surprise integrators: Basic authentication is now disabled by default five minutes after account creation. It can be re-enabled through account settings or the API, but any script or storefront integration relying on Basic auth against a freshly created account will start failing silently after that window . Separately, BTCPay removed public remote access to the LND API on Docker deployments as defensive hardening .

Two companion components must move with it. Operators were told to update NBXplorer to 2.6.10 and LND to 0.21.1 alongside the server itself; patching BTCPay while leaving either dependency behind leaves the stack in an untested configuration .

Worth stating plainly about scope: on-chain wallets, including BTCPay hot wallets, were not affected, and deployments running a different Lightning implementation — or no Lightning at all — were never exposed to the macaroon risk. Initial guidance to move on-chain funds was precautionary and was later withdrawn . Foundation CEO Zach Herbert, speaking on The Defiant, described the defect as sitting in BTCPay's authentication flows rather than in the LND client itself (video: The Defiant).

Already Patched? Here's Why You're Still Not Done

Installing BTCPay Server 2.4.2 removes the vulnerability, but it does not revoke credentials an attacker already copied. Macaroon files are bearer tokens: whoever holds a valid admin macaroon retains full LND node control — opening and closing channels, moving funds — regardless of which server version is running. The official advisory therefore treats rotation, not patching, as the step that actually closes the exposure . Any operator who updated on August 7 and stopped there is still running a node whose keys may be in someone else's hands.

The remediation checklist published alongside the release breaks into four concrete actions :

• Rotate macaroons and macaroons.db. Stolen macaroon files survive a software update intact. Updating through the BTCPay maintenance dashboard regenerates macaroons automatically, which is the lowest-friction path for most self-hosted operators; manual deployments need to delete and regenerate the credential store themselves.
• Refresh auth strings and API keys tied to the LND node. Connection strings embedded in BTCPay's Lightning settings, plus any third-party integrations or Greenfield API keys pointing at the same node, should be reissued — the 2.4.2 notes also disable Basic authentication by default five minutes after account creation, so older stored credentials may be stale as well as unsafe .
• Audit node activity. Review the LND logs for unrecognized peers, unexpected channel closures, and outbound payments you did not initiate. This is how the flaw surfaced in the first place: Sparrow Wallet developer Craig Raw lost funds, read his own logs, and reported what he found .
• Confirm the LND API is not publicly reachable. BTCPay pulled public remote access to the LND API on Docker deployments as a hardening measure . Operators running custom reverse-proxy or port-forwarding setups should verify the change actually took effect on their host rather than assuming the upgrade applied it.

Order matters. Rotate credentials before returning a node to normal operation, and treat log review as ongoing rather than one-time — an attacker holding old macaroons has no reason to act immediately. Operators who cannot complete rotation promptly were advised in the advisory to keep the server offline, which remains the conservative choice for anyone unsure whether their node was reachable before August 7 .

BTCPay Is the Third Bitcoin Infrastructure Hit in Two Weeks — Here's the Pattern

The BTCPay Server compromise was the third Bitcoin infrastructure failure in roughly a week, following the Coldcard hardware wallet sweeps that began circulating publicly on July 31 and the Boltz shutdown on August 3 . None of the four incidents in that window touched Bitcoin's consensus rules, signature scheme, or hashing — every one was an application- or infrastructure-layer defect, and BTC traded flat in the $64,000–$65,000 range throughout (video: CRYPTO NEWS 24) .

The Coldcard case is the most instructive, because it breaks the mental model most self-custody users rely on. The underlying defect was a firmware bug introduced around 2021 that impaired private key generation, and it sat undetected for roughly five years until advanced open-source AI models surfaced it (video: Good For Bitcoin) . Coldcard is fully air-gapped, so the affected devices had never connected to the internet — the weakness was baked into the keys themselves, not exposed through a network path. Galaxy Research put Coldcard-related losses at 1,719 BTC, about $111 million .

Boltz, the Lightning swap service, took a different route on August 3: rather than ship a fix, it suspended its infrastructure indefinitely, explicitly stating it could not patch faster than AI-assisted attackers were iterating . Zeus Wallet infrastructure also went offline in the same window after a separate attack, but with an important distinction — no customer funds were lost and no Lightning node software vulnerability was identified .

The pattern that links them is not a shared codebase but a shared discovery method. Both BTCPay and the researchers involved flagged that AI is changing the economics of vulnerability hunting: reviewing large, aging codebases is now fast and cheap enough that dormant bugs from 2021 get found in 2026 . That cuts both ways — the Bitcoin Red Team, a volunteer group using AI-assisted scanning, has surfaced roughly 4,962 potential issues across 390 Bitcoin projects, about 720 of them rated high or critical . For operators, the practical takeaway is that "audited years ago" is no longer a meaningful assurance, and that layer separation matters: consensus held, but everything built on top of it is now being re-examined at machine speed.

The $190,000 Bounty and Who's Chasing the Stolen Funds

On August 10, 2026, BTCPay Server supporters announced a recovery bounty worth 10% of any funds returned, capped at 3 BTC — roughly $190,000 at the time — and made it open to anyone with useful information, explicitly including the attacker . The structure is a standard white-hat off-ramp: return the coins, keep a defined percentage, avoid the laundering and enforcement risk that comes with the rest. It is not an admission of how much was taken. As of the reporting window, BTCPay had published neither an aggregate loss figure nor a count of affected Lightning nodes .

Alongside the bounty, the BTCPay Server Foundation directed money at the people who found and analyzed the flaw rather than exploited it: 0.21 BTC to Craig Raw, the Sparrow Wallet developer credited with the disclosure, and 0.21 BTC to the Bitcoin Red Team fund . Small sums against the losses, but they set a price signal for responsible disclosure in an ecosystem that has historically underpaid for it.

On the recovery side, BTCPay says it has engaged exchanges, blockchain analytics firms, and law enforcement to trace the stolen funds . Traders should calibrate expectations accordingly. Tracing works by flagging deposit addresses at regulated venues; funds routed through Lightning channel closures and then coinjoined or held indefinitely are far harder to freeze. Exchange cooperation is the realistic chokepoint, and it only bites if the attacker tries to cash out on-ramp infrastructure that performs KYC.

The project has also promised a full postmortem, plus stronger code-scanning and external review procedures going forward . For merchants deciding whether to stay on self-hosted infrastructure, that postmortem is the document to read before re-committing meaningful Lightning liquidity — it will show whether the fix was a patch or a process change.

Outlook: AI-Assisted Bug Hunting Is Now a Two-Sided Arms Race

AI-assisted code review is now the shared driver behind Bitcoin's application-layer failures, and it cuts both ways: the same tooling that finds bugs cheaply for volunteer defenders finds them just as cheaply for attackers. The Bitcoin Red Team, a volunteer security group that runs AI-assisted scans across Bitcoin codebases, has surfaced roughly 4,962 potential issues across 390 projects, of which about 720 were rated high or critical severity . That single backlog is larger than the volume of publicly disclosed Bitcoin infrastructure bugs in most prior years combined, and it exists because scanning legacy code got dramatically cheaper — not because the code got worse.

The Coldcard defect illustrates the shift precisely. That firmware bug was introduced around 2021 and sat undetected for roughly five years until advanced open-source AI models surfaced it (video: Good For Bitcoin) . Nothing about the code changed in 2026; the cost of reading it did. Boltz made the same calculation explicitly when it suspended its Lightning swap infrastructure on August 3, saying it could not patch faster than AI-assisted attackers were iterating .

For the rest of 2026, the practical expectation is compressed disclosure timelines and more emergency releases across self-hosted Bitcoin infrastructure. BTCPay's own commitment to stronger code-scanning and external review is a template other projects will likely copy . The near-term risk concentrates in a specific profile:

• Rarely-audited merchant payment stacks — self-hosted processors handling bearer credentials, where a single leaked file grants node-level control.
• Long-lived firmware — single-signature hardware wallet code paths written years ago and never re-reviewed, as the 1,719 BTC (~$111 million) in Coldcard-related losses demonstrated .
• Authentication glue code — the layers between components, which sit outside both projects' core review scope, exactly where the Greenfield Basic auth bypass lived .

None of the August incidents touched Bitcoin's consensus rules or cryptography . The concrete takeaway: treat self-hosted infrastructure the way you would treat an exchange account — assume the operational layer will eventually fail, cap what sits on a single hot Lightning node, split custody across implementations or multi-signature setups, and subscribe directly to each project's advisory feed rather than waiting for the news cycle. In an environment where a five-year-old bug can be found in an afternoon, patch latency is now the main variable you actually control.

Frequently asked questions

What is a macaroon in Bitcoin Lightning Network terms?

A macaroon is a bearer-token API credential used by LND (Lightning Network Daemon) to authorize requests to a node. Anyone holding the file can use it — there is no password prompt, no second factor, and no session to expire. LND issues several tiers, and the admin macaroon confers full control of the node: opening and closing channels and moving funds. That design is why a file-disclosure bug in BTCPay Server translated directly into drained nodes rather than merely leaked data .

Is BTCPay Server safe to use after the 2.4.2 update?

Version 2.4.2, released August 7, 2026, closes the vulnerability, but the update alone does not restore a compromised server to a clean state. Macaroon files copied by an attacker before the patch remain valid credentials afterward, because updating software does not invalidate previously issued bearer tokens. The advisory instructs operators to rotate macaroons and macaroons.db, refresh auth strings, and audit LND for unrecognized peers, unexpected channel closures, and payments they did not initiate. Updating through the maintenance dashboard regenerates macaroons automatically .

How much was stolen in the BTCPay Server macaroon exploit?

No aggregate figure exists. BTCPay Server has not published a total loss amount or a count of affected nodes, and self-hosted deployments make a full tally difficult by design. Named affected parties include Foundation, maker of the Passport hardware wallet, and Citadel21, plus Sparrow Wallet developer Craig Raw, whose own losses led him to analyze his logs and disclose the bug . For scale on the individual-merchant level, roughly 40% of Foundation's sales in the two weeks prior arrived over Lightning at an average purchase price of about $400 . Treat any circulating total as an estimate until the promised postmortem lands.

Is the BTCPay Server hack related to the Coldcard exploit?

Not technically. The two involve entirely different bug classes: Coldcard's was a firmware defect introduced around 2021 that impaired private key generation and went undetected for roughly five years, while BTCPay's was an authentication-flow flaw in server software that exposed credential files . They belong to the same August 2026 cluster of Bitcoin infrastructure failures — alongside Boltz suspending its swap infrastructure on August 3 — and share a common driver: AI-assisted code review made long-dormant bugs cheap to find. Galaxy Research put Coldcard-related losses at 1,719 BTC, about $111 million .

Were on-chain Bitcoin funds at risk, or only Lightning?

Only Lightning. The exposure was limited to nodes running LND, where stolen macaroons granted node control; on-chain wallets, including BTCPay hot wallets, were not affected, and deployments using other Lightning implementations or no Lightning at all faced no macaroon risk. Initial guidance to move on-chain funds was precautionary and later walked back . Foundation CEO Zach Herbert described the issue as specific to BTCPay's authentication flows rather than a defect in the LND client itself, and confirmed the on-chain hot wallet was untouched (video: The Defiant) .

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

Subscribe