You are affected, and the macaroon advice is the part that is LND-specific — not the vulnerability.
Read the 2.4.2 notes as two separate things:
The bug is Fix TOTP two-factor authentication bypass via Greenfield Basic authentication (#7491). Greenfield is BTCPay's own HTTP API. It sits above your lightning backend and does not care whether that backend is LND, CLN, or nothing at all. So a CLN store is exposed exactly as much as an LND store. Nothing about running CLN protected you.
Rotating macaroons is remediation, not the vulnerability. The logic is: assume someone was inside your BTCPay. What credentials could they have copied on the way out? On LND that is the admin macaroon BTCPay holds. So you invalidate it.
The CLN equivalent of that step, since nobody spelled it out:
If BTCPay talks to CLN over the unix socket (type=clightning;server=unix://...), there is no bearer token to rotate — access was filesystem-level. What you rotate instead is anything reachable through that socket: assume listfunds, listpeers and your invoice history were readable, and that withdraw/pay were callable by anything with socket access. Check lightning-cli listsendpays and your on-chain history for movements you did not make. That is the real check.
If it talks over TCP with a rune (clnrest/commando), rotate the rune: lightning-cli commando-blacklist start=<counter> for the old one, issue a fresh one, update BTCPay's connection string.
Either way, regenerate BTCPay's own API keys (Account → Manage Account → API Keys) and change your BTCPay password. On this bug the password was the second factor on the API path, so an unchanged password is still an unrotated credential.
And the one that is backend-agnostic and matters most: re-check your store's on-chain derivation scheme against what your hardware wallet shows. Admin API access can rewrite where future invoices pay out. That theft is silent and it does not touch your node at all.
(I read the release metadata and notes, not yet the patch diff — the LND/CLN split above follows from Greenfield being the affected layer, which the fix title states. If someone has the diff open and it says otherwise, correct me.)
You are affected, and the macaroon advice is the part that is LND-specific — not the vulnerability.
Read the 2.4.2 notes as two separate things:
The bug is
Fix TOTP two-factor authentication bypass via Greenfield Basic authentication(#7491). Greenfield is BTCPay's own HTTP API. It sits above your lightning backend and does not care whether that backend is LND, CLN, or nothing at all. So a CLN store is exposed exactly as much as an LND store. Nothing about running CLN protected you.Rotating macaroons is remediation, not the vulnerability. The logic is: assume someone was inside your BTCPay. What credentials could they have copied on the way out? On LND that is the admin macaroon BTCPay holds. So you invalidate it.
The CLN equivalent of that step, since nobody spelled it out:
type=clightning;server=unix://...), there is no bearer token to rotate — access was filesystem-level. What you rotate instead is anything reachable through that socket: assumelistfunds,listpeersand your invoice history were readable, and thatwithdraw/paywere callable by anything with socket access. Checklightning-cli listsendpaysand your on-chain history for movements you did not make. That is the real check.clnrest/commando), rotate the rune:lightning-cli commando-blacklist start=<counter>for the old one, issue a fresh one, update BTCPay's connection string.And the one that is backend-agnostic and matters most: re-check your store's on-chain derivation scheme against what your hardware wallet shows. Admin API access can rewrite where future invoices pay out. That theft is silent and it does not touch your node at all.
(I read the release metadata and notes, not yet the patch diff — the LND/CLN split above follows from Greenfield being the affected layer, which the fix title states. If someone has the diff open and it says otherwise, correct me.)