BTCPay Server warned operators on August 7, 2026 that a critical vulnerability is being actively exploited and can result in loss of funds, and shipped emergency release v2.4.2 the same day. The project’s instruction was blunt: update immediately, or shut the server down until you can.

Six hours later BTCPay published a fuller security advisory that narrowed the blast radius and withdrew one of its own emergency instructions. If you acted on the first thread and stopped reading, the section below is the part you need.

What broke

BTCPay Server is free, open-source, self-hosted software that lets merchants and individuals accept Bitcoin (on-chain and Lightning) without routing payments through a custodial processor. You run the stack; you hold the keys and the operational risk.

The exploited flaw let an unauthenticated remote attacker retrieve .macaroon credential files belonging to LND, one implementation of a Lightning node. Macaroons are the bearer credentials that authorize actions on that node — hand them to an attacker and they can control it and move funds out. BTCPay says the attacks it reviewed targeted only files with the .macaroon extension.

BTCPay is not publishing technical details yet so operators have time to update — a defensible call mid-incident, and one that leaves the exact bug class non-public for now.

Scope matters here, because the advisory is narrower than the first alert implied:

  • LND deployments carry the credential risk. Other Lightning implementations and instances not running Lightning at all are not exposed to it — though BTCPay still strongly encourages everyone to update.
  • BTCPay’s own on-chain wallets, including hot wallets, are not affected. Funds sitting in LND’s internal on-chain wallet are part of the compromised node and can still be at risk.

Version 2.4.2 also upgrades LND to 0.21.1 and automatically regenerates its macaroons on standard installations, and temporarily removes public access to the LND API on Docker deployments — so an external wallet such as Zeus will not connect through your BTCPay domain or onion address for now. Credit for the disclosure goes to Craig Raw of Sparrow Wallet, with the Bitcoin Red Team effort helping analyze the exploit.

The other fix in the same release

Worth separating, because it has been widely conflated: 2.4.2 also patches a TOTP two-factor bypass on the Greenfield API, and that is a distinct issue, not the one under active exploitation.

Per pull request #7491, merged August 4 by maintainer Nicolas Dorier and reported by Ben Carman (@benthecarman), Basic authentication only checked whether an account had FIDO2 credentials. Users who protected the UI login with a TOTP authenticator app alone could still call the full API with just email and password, at unrestricted permissions — a gap between the UI’s security model and the API’s, though rate limits still throttled password guessing.

A related change disables Greenfield Basic authentication by default five minutes after account creation, with opt-in through settings or the API.

Who felt it

BTCPay has not published a total stolen amount, confirming only that users were affected and funds taken. CoinDesk named hardware-wallet maker Foundation — whose CEO Zach Herbert said its node was drained overnight, channels closed and funds swept — and bitcoin zine Citadel21 among operators reporting swept nodes. Treat those as multi-outlet coverage of a live incident, not a closed forensic ledger.

What BTCPay walked back

The first advisory thread, posted the same afternoon, told operators to refresh macaroons and macaroons.db, refresh auth strings for other Lightning backends, and — if you generated a hot on-chain wallet inside BTCPay — move those funds and recreate the wallet.

That last instruction has since been withdrawn. In the formal advisory BTCPay wrote that it had advised moving funds out of BTCPay on-chain wallets “out of an abundance of caution,” and that after further review it confirmed only LND is impacted. On-chain wallets, hot ones included, are not affected.

Moving coins is not free — you pay fees, you touch keys, you risk fat-fingering an address under time pressure. Operators who followed the first thread spent both on a precaution that turned out to be unnecessary. That is not a scandal; it is what good-faith emergency response looks like while the picture is still forming. It is a reason to follow an incident to its resolution rather than acting once and closing the tab.

What operators should do now

  1. Update to 2.4.2 via Server Settings → Maintenance → Update. Confirm the footer shows 2.4.2 and that LND reports 0.21.1. If you run LND and cannot update yet, take the server offline — do not leave an affected deployment reachable from the internet.
  2. Audit your LND node. Look for payments you did not make, unexpected channel closures, unfamiliar peers, and balances that disagree with your own records.
  3. Mind credentials you manage yourself. The update regenerates macaroons automatically on standard installs, but if you expose LND through your own reverse proxy, Tor service or forwarded port, rotate those credentials yourself — updating BTCPay does not close access paths outside it.
  4. Expect the Zeus/external-wallet gap on Docker installs until BTCPay restores public LND API access.
  5. Prefer scoped Greenfield API keys over long-lived Basic auth. The release’s default clamp on Basic auth nudges the same way.

This is application-layer risk, not a break of Bitcoin’s consensus rules — the failure mode is the software holding Lightning permissions next to the invoice engine.

Why merchant rails care

BTCPay sits where ideology meets inventory: the café or co-op that takes sats without routing every sale through an exchange. That model is popular precisely because it cuts out middlemen, and the cost is that you are the security team — no SaaS provider is pushing a silent patch to every tenant at once.

For Latin American merchants already using Bitcoin rails for tourism, freelancing, or inflation hedges, the lesson is about attention as much as architecture. Self-hosting puts you on the distribution list for your own emergencies: you have to see the alert, apply it, then keep watching as the advisory sharpens. Subscribe to the project’s releases, not just its X account. And as ordinary hygiene rather than incident response, keep treasury in cold storage and multisig, and leave only working float on the node.

Takeaway

On August 7, BTCPay Server said a critical flaw was under active exploit, published 2.4.2, and told unpatched operators to go offline until they upgraded. The exploited bug exposed LND macaroon credentials to unauthenticated attackers; the TOTP 2FA bypass in the same release is a separate issue. BTCPay later confirmed the risk is LND-specific and that on-chain wallets, hot ones included, are not affected — retracting its initial advice to move those funds.

If you run BTCPay with LND, treat this as live until 2.4.2 and LND 0.21.1 show in the footer and your node’s history looks clean. Self-hosted payments still beat custodial lock-in, but only if the operator ships the patch — and reads the follow-up. This is a security operations note, not investment advice.

Sources