BTCPay Server's Stolen Macaroons: Why Updating to 2.4.2 Does Not End It

TL;DR

On August 7, 2026, BTCPay Server told every operator to update to version 2.4.2 or shut the server off. Attackers were already inside. The advisory states it without hedging: "We have confirmed that attackers exploited this vulnerability. Users were affected and funds were stolen." What the attackers collected first were .macaroon files, the credentials that authorize commands against an LND Lightning node. Holding those, they closed merchants' payment channels and swept the settled balances on-chain. Foundation, the company behind the Passport hardware wallet, and the Bitcoin publication Citadel21 both reported drained nodes before the public alert went out. No loss total has been disclosed. A version bump closes the hole, and it does nothing to un-copy a credential, which means this incident is still open on every server whose operator updated and stopped there.

What Did the Attackers Actually Take?

A macaroon is a bearer credential. LND writes it to disk as a file, and whatever holds a copy of that file can issue the commands the file permits. The admin.macaroon that BTCPay Server needs in order to drive a node contains no caveats at all, which is to say unrestricted access to the node's RPC surface. Copy the file, and for every practical purpose you are the node operator. That is a macaroon.

The theft of the credential and the theft of the money are two separate events, and the second one needed no exploit. A Lightning channel is funded by an on-chain output two parties jointly control, and closing it settles each side's balance to an address the closing node picks. An attacker with admin RPC authority can force every channel shut and direct the proceeds anywhere. Foundation's chief executive Zach Herbert described that outcome: the company's BTCPay Lightning node was drained overnight, its channels closed and the funds swept. Citadel21 reported the same pattern on a node that held little money.

Every call in that sequence is a documented, ordinary node operation, which is why nothing after the credential read stands out in the node's own logs.

The Bug BTCPay Published: A Guard That Counted the Wrong Credential

The one authentication flaw whose code is public is a two-factor bypass in the Greenfield API, BTCPay's REST interface.

Pull request #7491 landed on August 4, 2026. The file is BTCPayServer/Security/GreenField/BasicAuthenticationHandler.cs, and lines 78 to 90 were meant to block Basic authentication for any account with multi-factor authentication turned on. The condition it actually evaluated was user.Fido2Credentials.Any(). The report filed against it puts the consequence in one sentence: "TOTP-only users (flag AuthenticatorEnabled, no FIDO2 row) can call the entire ~/api/v1/* API with just email:password and get an unrestricted permission claim. The UI login correctly forces these users through 2FA, so this is a real gap."

The guard asked whether a hardware security key was registered. The question it needed to answer was whether two-factor authentication was enabled. Anyone using an authenticator app and no FIDO2 key held an account that the web interface treated as protected and the API treated as single-factor. The fix replaced the test with await signInManager.IsTwoFactorEnabledAsync(user), which reports on the policy rather than on one way of satisfying it.

This is CWE-288, authentication bypass using an alternate path or channel: "The product requires authentication, but the product has an alternate path or channel that does not require authentication." The web UI was the enforced path. The API was the alternate one.

The repository's own API timestamps put the report at 19:11 UTC and the merge at 19:32 UTC, a 21-minute turnaround. Version 2.4.2 shipped a blunter mitigation alongside it: Greenfield Basic authentication is now disabled by default five minutes after an account is created, opt-in only, on every account rather than only the ones the bug touched.

Was That the Bug That Drained the Nodes?

Probably not, and the difference changes what operators should assume about their own exposure.

Most coverage of this incident tied the drain to #7491, because it is the only vulnerability in 2.4.2 with a public description. Three things in the record argue that the exploited flaw is a different finding:

1. The reporters differ. Pull request #7491 credits the report to the developer @benthecarman. The advisory credits Craig Raw, working with the Bitcoin Red Team, for the vulnerability that was being exploited.
2. The authentication requirement differs. The advisory describes "an unauthenticated remote attacker." The Greenfield bypass needs a valid email address and password, and the person who reported it noted that existing rate limits kept brute force off the table.
3. The disclosure posture differs. BTCPay withheld the technical details of the exploited flaw while operators were still patching. #7491 has been fully described in a public repository since the day it was merged.

Read together, 2.4.2 carries at least two authentication fixes, and the one attackers were actually using is the one nobody has described.

The shape of the emergency mitigations is suggestive about where it lives. Version 2.4.2 installs LND 0.21.1, regenerates macaroon credentials automatically on standard installations, and cuts external wallets such as Zeus off from reaching the node through a BTCPay domain or a Tor onion address on Docker deployments. That last item is a functionality regression the project accepted under time pressure, and it points at a publicly reachable route to the node's credentials rather than at an account-authenticated one. That is an inference from the remediation, not something BTCPay has confirmed, and it should be read as an inference.

The operational consequence is clear either way. Until the mechanism is published, any server that was internet-reachable on a pre-2.4.2 version has to be triaged as though an unauthenticated stranger read its macaroons, because that is what the vendor says happened. A strong unique password is not a reason to skip rotation.

The Attack, Step by Step

The update closes steps 1 through 5. Step 6 stays open until the operator acts, which is why the advisory's remediation list runs longer than its patch instruction.

Why 2.4.2 Does Not Close Your Incident

Updating stops new theft. It does not invalidate what was already taken.

Deleting the exported .macaroon files is not revocation. The authority those files carry derives from a root key held in macaroons.db, and LND's own documentation is explicit about what invalidation requires: "If you delete the data directory which contains the macaroons.db file, this invalidates the admin.macaroon, readonly.macaroon and invoice.macaroon files." There is a related trap for anyone who believes they have already rotated. Running changepassword on the wallet leaves the macaroon root key untouched, so macaroons issued before the password change stay valid unless --new_mac_root_key is passed.

Version 2.4.2 does regenerate macaroons automatically, and only on standard installations. Anyone on a non-standard deployment, or whose node is reachable through a path they administer themselves such as an external reverse proxy or a Tor hidden service pointed at LND rather than at BTCPay, falls outside that. The advisory tells them to rotate separately, because an update cannot close an access route it does not know about.

The macaroon is also not the only credential a compromised server may have given up. Both the advisory and subsequent reporting tell operators to move funds out of any BTCPay-generated on-chain hot wallet and recreate it.

An operator who updated, watched payments start working again and moved on has closed the door and left a working copy of the key in circulation.

Coldcard, Eight Days Earlier: The Same Shape of Mistake

The other Bitcoin infrastructure failure of the same fortnight was, at the level of the source code, the same error.

Coinkite's technical account of the Coldcard entropy failure identifies the defect precisely: "The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build." Seed generation silently fell back to a software pseudorandom number generator, leaving roughly 40 bits of effective search space on Mk2 and Mk3 devices and roughly 72 bits on Mk4, Mk5 and Q. Galaxy Research's on-chain mapping put the resulting sweep at 1,367.05 BTC across 4,585 addresses, about $88.6 million, a figure that rose with each round of analysis. We covered that failure in detail in the Coldcard entropy writeup.

Put the two guards next to each other.

Coldcard's build test looked for a macro's existence when what mattered was its value. BTCPay's handler looked for a FIDO2 row when what mattered was whether any second factor was switched on.

Both compiled. Both read as deliberate to a reviewer, because in each case the code checks something real and closely correlated with the right answer. A proxy check holds until an input arrives where the proxy and the property disagree, and someone constructs that input eventually. Coldcard's divergence took five years to surface.

This is the part of the audit story that gets skipped. An audit certifies the code you showed it against the questions somebody thought to ask, and a guard that tests a correlated attribute passes a reading, then passes a test suite built on the same assumption, and keeps passing until the property it stands in for is the one that matters.

Why This Matters Beyond Bitcoin Payment Servers

Every authentication surface is a separate implementation of your policy, and the second one is the one nobody reviews. BTCPay's web interface enforced two-factor authentication correctly. The REST API, added later for different consumers, reimplemented the same decision and got it wrong. Any product that grows an API, a mobile client or a CLI owes the same authorization answers in a second place, with no compiler to report that the two disagree.

A file-based bearer credential with no expiry converts a single read into permanent access. Macaroons carry no expiry by default, and revocation means destroying a root key rather than deleting a token. Any credential of that shape your application can read is one it can leak, and the blast radius is whatever the credential still authorizes months later. It is the standing ERC-20 approval from the Jared honeypot in a different stack.

Machine-assisted review has compressed the time from bug-exists to bug-known, for both sides. The Bitcoin Red Team, a volunteer effort assembled after the Coldcard disclosure, filed 4,962 findings across 390 open-source Bitcoin projects in 27.5 hours on August 4 and 5, including 85 critical and 635 high-severity issues, with 16 researchers and AI tooling, funded with close to $40,000 from OpenSats. Days later one of the ecosystem's most widely deployed payment servers was being exploited through an authentication flaw. Attackers run the same tooling: Coinkite's account of the Coldcard failure, as reported by Decrypt, said someone used AI to review previous versions of its firmware. A finding sprint is a defensive act that also starts a clock, and the window between a fix landing in a public repository and operators deploying it is the most valuable one an attacker has.

What Operators Should Do Now

1. Treat updating and rotating as two separate jobs. Deploy 2.4.2, then rotate. Doing only the first stops further exfiltration and revokes nothing.
2. Destroy the macaroon root key, not the macaroon files. Invalidation comes from removing macaroons.db, or from changepassword with --new_mac_root_key. Deleting admin.macaroon and letting LND write a new one against the same root key changes nothing for an attacker holding the old copy.
3. Rotate every credential path you administer yourself. External reverse proxies and Tor hidden services that terminate at LND rather than at BTCPay are invisible to the update, and the advisory calls them out specifically.
4. Move any BTCPay-generated on-chain hot wallet and recreate it. A server that leaked one credential should not be assumed to have leaked only that one.
5. Reconstruct the timeline your node can still prove. The advisory's checklist is the right one: unauthorized payments, unexpected channel closures, unfamiliar peers, and balance discrepancies on-chain or in Lightning. Closures are the highest-signal item, since a merchant node shutting channels in bulk is one of the loudest events Lightning produces.
6. Search your own auth code for guards that test an artifact instead of a policy. HasFido2(), #ifdef FEATURE, if (apiKey != null), roles.Any(). Each is a claim that presence implies state, and each deserves replacing with a call that answers the actual question.
7. Give externally consumed credentials a scope and an expiry. LND can bake restricted macaroons for exactly this reason. BTCPay itself needs admin authority, and the wallet on your phone does not.

This incident splits cleanly, so it is worth saying which half we would have helped with. The published Greenfield bug is code in an authentication handler on a public repository, and a volunteer review pass did find it. Human review and automated scanning catch that class, which is what our Full Audits and Sentinel work is for, and neither would have prevented the drain once a credential was copied. Runtime monitoring makes a narrower claim we will not inflate: it does not stop a macaroon read, and the interval between the first unexpected channel close and the last sweep is the window Tripwire exists to shorten. Foundation found out in the morning.

What is still missing is substantial. As of August 10, 2026, BTCPay has published neither the mechanism of the exploited flaw nor a count of affected servers nor a loss total, which leaves operators patching against a description rather than a bug they can test for. No attacker addresses and no laundering trail have been published either, so there is no on-chain account of where the swept balances went, and we are not going to guess at one. Nobody outside the project can say how many nodes now run 2.4.2 with a macaroon root key an attacker copied last week. That population is the real size of this incident, and no one has counted it.

Frequently Asked Questions

Was BTCPay Server itself hacked, or were merchants' nodes hacked? Neither framing is quite right. The flaw was in BTCPay Server software that merchants self-host, so each affected operator ran their own vulnerable instance. It surrendered the credentials for the LND node attached to it, and the theft happened on that node using legitimate commands.

How much bitcoin was stolen in the BTCPay Server exploit? No total has been published. BTCPay confirmed that funds were stolen without quantifying it, and reporting has established two named victims, Foundation and Citadel21, neither of which disclosed an amount. Treat any circulating figure as unsourced until the project or an on-chain analysis provides one.

Does updating to 2.4.2 make my node safe? It closes the vulnerability and, on a standard installation, regenerates your macaroons. It does not invalidate credentials copied while you were exposed unless the macaroon root key is replaced, and it does not touch access routes you configured yourself outside BTCPay.

How do I actually revoke an LND macaroon? Remove the macaroons.db file so the root key is regenerated, or run changepassword with the --new_mac_root_key flag. Deleting only the .macaroon files leaves the underlying root key intact, and any macaroon minted from it stays valid.

I run BTCPay Server with Core Lightning, or with no Lightning at all. Am I affected? The advisory scopes the credential exposure and the fund theft to LND deployments. Operators on other Lightning implementations or with Lightning disabled should still update, because the published Greenfield authentication bypass is not LND-specific and grants broad API access to the account.

Sources / References

• BTCPay Server, Security Advisory: Update BTCPay Server to 2.4.2 Immediately
• BTCPay Server v2.4.2 release notes
• BTCPay Server pull request #7491, Fix: TOTP 2FA bypass via Greenfield Basic auth
• LND documentation, Macaroons
• CWE-288: Authentication Bypass Using an Alternate Path or Channel
• CoinDesk, Another Bitcoin infrastructure exploit hits, this time draining Lightning payment servers
• Cointelegraph, BTCPay restricts remote Lightning access after attackers steal funds
• The Block, BTCPay warns of actively exploited vulnerability that could drain funds
• TFTC, BTCPay Server v2.4.2 patches live LND macaroon exploit draining Lightning nodes
• Coinkite, Entropy technical backgrounder
• The Hacker News, Coldcard hardware wallet flaw linked to Bitcoin theft
• Crypto Briefing, Bitcoin Red Team files 4,962 findings in 27.5 hours
• Decrypt, Bitcoin AI security audit files 4,962 findings across 390 projects