BTCPay Server Was Handing Out Lightning Node Keys To Anyone Who Asked

BTCPay Server published version 2.4.2 on 7 August with a line at the top of the release notes that leaves no room for interpretation: “This release contains fix of a critical vulnerability that is being actively exploited. You need to update as fast as you can.”

The advisory that followed the same evening says what was taken. An unauthenticated remote attacker could obtain the .macaroon credential files for a connected LND node. The project’s own words: “We have confirmed that attackers exploited this vulnerability. Users were affected and funds were stolen.”

Why a macaroon is the whole node

A macaroon is LND’s authentication credential. The admin macaroon is not a password to a dashboard, it is the key to the node’s API, and the API is the node: open channels, close channels, send payments, drain the balance. There is no second factor behind it and no confirmation step. Whoever holds the file holds the funds.

So this was not an escalation chain. It was a request, made without a password, a session or two-factor authentication, that returned the credential granting full control of a Lightning node.

What is and is not affected

The advisory is precise about scope, and the distinction is worth reading carefully before anyone panics about the wrong wallet:

If you run BTCPay Server for on-chain payments only, this is a routine update. If you connected it to a Lightning node at any point, it is not.

What to do, in the order the project gives it

1. Update to BTCPay Server 2.4.2, and LND to 0.21.1. Two updates, not one, and the second is the one people will skip.
2. Confirm it took. The admin footer should read 2.4.2.
3. Read your node’s recent activity. Unauthorised payments, unexpected channel closures, balances that do not reconcile.
4. Credentials are regenerated by the update, and manual rotation is available if you want to be certain.
5. If LND is reachable from outside through a custom reverse proxy or over Tor, rotate immediately rather than relying on the automatic step.

For anyone who cannot patch straight away the instruction is blunt: “take the server offline until you can.” An exposed instance is handing out node credentials for as long as it is running, so downtime is the cheaper option.

Version 2.4.2 also temporarily restricts public LND API access on Docker deployments, which is a sensible belt-and-braces move while operators catch up.

The LND version is not optional, and here is why

Updating BTCPay alone leaves the door ajar, and the reason is a detail of how macaroons work. Deleting a macaroon file does not revoke the macaroon. The credential is signed by a root key held by the node, and any copy an attacker already took stays valid as long as that root key does. Rotating the file without rotating the key is housekeeping, not revocation.

That is what the LND 0.21.1 requirement is for. Update BTCPay, skip LND, and a stolen credential from yesterday still works tomorrow.

The same logic applies to anyone who has moved on. If BTCPay Server was ever pointed at a Lightning node, even one you no longer use, that node’s credentials should be rotated regardless of what the server is connected to now.

Found by a person, in the logs

The vulnerability was reported responsibly by Craig Raw, the developer behind Sparrow Wallet, with the Bitcoin Red Team assisting in analysing the exploit. The same 2.4.2 release separately fixes a TOTP two-factor authentication bypass via Greenfield Basic authentication, reported by Red Team members @brunoerg and @benthecarman, and now disables Greenfield basic authentication by default five minutes after account creation. Integrators are told to move NBXplorer to 2.6.10 at the same time.

Two independent authentication failures in one release is the part worth sitting with. One let an unauthenticated caller take a Lightning credential; the other let an authenticated caller walk past two-factor. Both are the same category of bug: a door that was supposed to check who you were and did not.

Self-hosting moves the risk, it does not remove it

BTCPay Server exists so that a merchant can take bitcoin without a payment processor standing between them and their money. That is a real benefit and this does not change the argument for it.

It does change who is on call. A custodial processor with this bug patches it centrally and most customers never learn it happened. Self-hosted software patches when the operator reads the advisory, which for a small merchant might be Monday. Every hour before then is a window someone else is scanning for, and the project told operators to take servers offline precisely because it could not close the window for them.

The trade is sovereignty for operational duty, and the duty is not theoretical. It is reading a security advisory on a Friday night and doing something about it before morning.