BTCPay Server Breach: Patch Closes Flaw but Stolen Credentials Survive

Merchants and service operators running BTCPay Server — the open-source, self-hosted Bitcoin payment processor powering commerce for thousands of businesses — discovered last Friday that their Lightning Network nodes had been emptied by attackers who exploited a logic error in the software's API authentication layer. The thefts were already underway when BTCPay posted its public warning at 11:51 a.m. ET on August 7: hardware wallet maker Foundation and the Bitcoin publication Citadel21 each had their Lightning nodes swept and channels force-closed before the advisory reached most of the affected operators.

What makes the incident particularly dangerous — and what most coverage has underweighted — is that updating the software alone does not fully close the exposure. Stolen macaroon credential files, which Lightning Network nodes use for API authentication, survive a software update intact. Any attacker who exfiltrated those files during the exploitation window retains access to the node until the operator explicitly deletes and regenerates them. Patching without rotating credentials is incomplete remediation. Lightning macaroon bearer credentials work as a bearer-credential system — like a session cookie that can be copied and used indefinitely until the underlying root key is destroyed.

BTCPay Server's Greenfield API — the interface used by external integrators, automated systems, and wallet backends to interact with server instances — supports two authentication methods: scoped API keys (with limited permissions per key) and Basic Authentication (email and password, with full account access). The Greenfield API authorization documentation describes both modes and their intended use cases.

The vulnerability, documented in GitHub pull request #7491 , was a logic error in how Basic Authentication handled two-factor authentication. When a user protected their account with a TOTP authenticator app — the standard "scan a QR code, enter a six-digit code" 2FA method — the Greenfield API's authentication code checked whether valid FIDO2 (hardware security key) credentials were registered on the account. Since most users protecting accounts with an authenticator app had no FIDO2 hardware key registered, the check returned false, and the API skipped the second factor entirely.

The result: any account with TOTP-based two-factor authentication could be accessed through the Greenfield API using only an email address and password. The browser login page enforced 2FA correctly throughout the vulnerability window — the bypass existed exclusively in the API layer, making it difficult for operators to detect through normal usage. The fix in v2.4.2 corrects the logic to check whether 2FA is actually enabled rather than whether a specific credential type is registered. The BTCPay v2.4.2 release also disables Basic Authentication by default five minutes after account creation, with operators able to re-enable it through account settings if an integration requires it.

Importantly, BTCPay founder Nicolas Dorier clarified publicly that this actively exploited flaw is distinct from a separate two-factor authentication bypass that had already been disclosed and patched on August 4. After a user circulated an AI-generated explanation attributing the attack to that earlier, already-fixed issue, Dorier corrected the record: the bug that attackers exploited was discovered by the Bitcoin Red Team and had not been previously disclosed. A full technical post-mortem is forthcoming once the team has processed the vulnerability's full scope.

This is the detail that separates this incident from a simple "update and move on" scenario.

Lightning Network nodes operated through BTCPay authenticate API requests using macaroon files — bearer credential tokens, similar in concept to session cookies, that are generated by the node and stored as files on the server. LND (Lightning Network Daemon), the most common Lightning backend, generates three default macaroons at startup: an admin macaroon with full access, a read-only macaroon, and an invoice macaroon. The LND macaroon documentation explains that these files persist on disk and that invalidating them requires explicit deletion of the root key database.

Unlike a password, a macaroon is a file — and files can be copied. An attacker with access to a BTCPay Server instance during the exploitation window, through the authentication bypass, could have exfiltrated these files. Once a macaroon file is in an attacker's possession, it provides full access to the Lightning node until the operator explicitly deletes the underlying root key file ( macaroons.db ) and regenerates all credentials. Applying the v2.4.2 software update does not touch these files.

This is why Kaloudis of the ZEUS wallet team warned operators bluntly: "Don't assume you're safe after upgrading." The credential-persistence risk is consistent with what victims described — channels force-closed and balances swept rather than evidence of an ongoing breach — suggesting attackers in some cases may have copied credentials during the exploitation window and subsequently drained nodes before or after the patch was released.

BTCPay's remediation guidance accordingly extends well beyond updating the software.

The flaw was not caught by automated scanning. The Bitcoin Red Team — a volunteer security research group that formed in response to the earlier Coldcard hardware wallet firmware failure — had spent the preceding week conducting an intensive AI-assisted audit of Bitcoin's open-source ecosystem. Sixteen researchers, funded by approximately $40,000 from OpenSats, filed 4,962 findings across 390 projects over 27.5 hours, averaging 180 findings per hour. The Bitcoin Red Team audit summary documents 85 critical issues and 635 high-severity findings across the ecosystem.

The BTCPay authentication bypass was not among them. As Dorier acknowledged publicly: "The AI report we got from the 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."

The flaw surfaced instead because Craig Raw — the developer behind the widely used Sparrow Wallet desktop client — lost funds from his own node and traced what happened through his server logs. "We got extremely lucky that a dev was impacted who could analyze the logs to understand what was going on," Dorier wrote. The gap between the Red Team's AI-assisted volume audit and the type of subtle logic-level error that caught Raw's node underscores a structural challenge: automated tooling produces findings at scale, but application-layer logic errors may still require a human — sometimes one who has already suffered a financial loss — to catch what a scan overlooks.

Zach Herbert, CEO of Foundation — the company behind the Passport hardware wallet — confirmed that his organization's Lightning node was emptied before the public warning reached him. Only the Lightning node used for payment processing was hit; the company's primary hot wallet was untouched. Hodlonaut, the pseudonymous operator of the Bitcoin publication Citadel21, reported the same pattern: node swept and channels force-closed. At least one other operator reported identical outcomes in public responses to BTCPay's advisory.

No aggregate dollar total for BTCPay-specific losses has been published. What is quantifiable is the structural exposure: the Lightning Network currently connects 6,280 nodes across 21,221 channels with 2,818.49 bitcoin in aggregate capacity — roughly $182 million at current prices — and research published by River in February 2026 found that Lightning usage surged 300% in 2025, exceeding $1 billion in monthly volume. As that volume grows, vulnerabilities in the payment infrastructure that operators use to connect their nodes carry proportionally greater consequences.

BTCPay's advisory arrived as the third significant security incident to hit Bitcoin's surrounding infrastructure since the end of July. The first, and by far the most damaging, was a firmware vulnerability in Coldcard hardware wallets: a March 2021 firmware build silently routed seed generation through a software pseudorandom algorithm rather than the device's dedicated hardware random number generator, reducing effective entropy from the 128-bit standard to approximately 40 bits. By the time researchers identified the pattern, four waves of automated sweeps had drained more than 1,816 bitcoin — roughly $114 million — from over 5,200 addresses. The CoinDesk report on Coldcard losses documented the fourth sweep as losses approached $114 million. The attack affected single-key addresses and appears to have been partially LLM-assisted, with researchers noting that an AI model could reconstruct the vulnerable key space from the public firmware code.

The second incident came on August 3, when the Lightning swap bridge Boltz suspended service indefinitely, citing an inability to patch faster than attackers were iterating.

The BTCPay Server exploit is the third event in the sequence. None of these incidents affected Bitcoin's consensus protocol or cryptography. Bitcoin traded near $64,800 on Friday, up roughly 0.7% over 24 hours, with no visible market reaction to any of the infrastructure failures. That resilience at the base layer, however, offers no protection to operators who depend on the software stack built atop it: for them, the losses are real and, in some cases, unresolved.

The BTCPay incident illustrates a structural property of self-hosted Bitcoin infrastructure that is easy to overlook: there is no central operator. When BTCPay published its emergency advisory, it had no mechanism to force an update to any deployment. Every affected operator — every merchant, every exchange, every service running an older version — had to find the notice, apply the update, and complete the post-patch credential rotation on their own infrastructure, each on their own timeline.

That decentralization is the model's core value proposition: operators control their own nodes without relying on a third party. It is also its security liability: in an active-exploitation scenario, the gap between when a patch is released and when the last vulnerable server updates is measured in hours to days. Attackers exploited that gap at Foundation and Citadel21 before the advisory ever reached their operators.

The response to this incident is multi-step. Completing only step one — updating the software — is insufficient.

Update immediately to BTCPay Server v2.4.2 through Admin Dashboard → Server → Maintenance → Update. Confirm the version string in the footer reads "2.4.2." If unable to update, take the server offline immediately; a server that is off cannot be exploited. Instructions are in the v2.4.2 release notes .

Update NBXplorer — BTCPay's wallet-tracking backend — to version 2.6.10. Operators running integrated deployments need this companion update. The NBXplorer releases page contains the update.

Rotate all Lightning node credentials. Delete the macaroons.db file and all individual macaroon files, then restart the Lightning node to regenerate them. For LND-based deployments, this means deleting admin.macaroon , invoice.macaroon , readonly.macaroon , and macaroons.db . Do not assume the node is secure until this rotation is complete.

Move on-chain hot wallet funds. Any on-chain hot wallet generated within BTCPay should be emptied and recreated from a fresh wallet. An attacker who had access during the exploitation window may have copied the keys.

Switch to scoped API keys. Going forward, BTCPay explicitly recommends scoped API keys over Basic Authentication for all Greenfield API integrations. Scoped keys limit what any single compromised credential can authorize; Basic Authentication provides full account access. The Greenfield API key documentation covers implementation. With v2.4.2, Basic Authentication is now disabled by default five minutes after account creation.

The flaw was a logic error in BTCPay's Greenfield API authentication code. When an account was protected by a TOTP authenticator app, the code checked whether a different type of credential — a FIDO2 hardware key — was registered, rather than whether two-factor authentication was actually enabled. Because most users securing accounts with an authenticator app had no FIDO2 key on file, the API skipped the second factor entirely, allowing access with only an email address and password. The risk applied to any operator running a BTCPay Server version before v2.4.2 who had enabled the Greenfield API — which is standard for Lightning Network node integrations and most automated merchant setups. The full technical fix is documented in GitHub pull request #7491 .

The software patch fixes the authentication logic going forward, but it does not invalidate credentials an attacker may have stolen during the exploitation window. Lightning node authentication relies on macaroon files — bearer credential tokens stored as files on the server. If an attacker copied those files before the patch was applied, they retain access to the node even after the software is updated. Operators must explicitly delete the macaroons.db file and all associated macaroon files and restart the node to generate fresh credentials. Only after that rotation is the node's credential set confirmed clean. The LND macaroon documentation explains why deleting only the individual macaroon files — without removing the root key database — is insufficient.

No. The vulnerability existed in BTCPay Server's application code, not in Bitcoin's consensus rules or cryptography. Bitcoin's base protocol was unaffected. Lightning Network payment channels are also built on Bitcoin's cryptography, which was not compromised. The losses affected individual operators' Lightning nodes — funds stored in channels connected to BTCPay instances — not the broader network. Bitcoin's price showed no significant reaction, trading near $64,800 on August 7.

This is the most instructive question from the incident. The Bitcoin Red Team, funded by approximately $40,000 from OpenSats, used AI-assisted tooling to file 4,962 security findings across 390 Bitcoin open-source projects in 27.5 hours. The BTCPay authentication bypass was not among them. As Dorier explained, the bug was "really sneaky" — a subtle logical condition in authentication middleware rather than the type of dangerous code pattern automated scanners reliably flag. The flaw was ultimately discovered because a developer (Craig Raw of Sparrow Wallet) lost funds and was able to trace the attack vector through server logs. A summary of the Red Team's broader findings is available in the full Bitcoin Red Team report . Automated tooling excels at volume and pattern recognition; application-layer logic errors that require understanding the intended semantics of a check may still require human investigation to surface.