A hardware wallet protects a seed by never letting it leave the device. A Lightning node does the opposite for its own authority. It writes a small file called a macaroon, and whoever holds that file can pay invoices, open and close channels, and sweep the on-chain wallet, no seed required. Over the past six weeks two popular self-hosting stacks admitted that strangers could reach those files from the open internet. If you run a node and have never rotated its credentials, you are trusting every app, bot, and backup you ever connected to have kept a perfect secret.
The credential that is the node
LND creates three macaroon files at startup: admin (no restrictions), readonly, and invoice. Every wallet app, payment processor, and automation script you connect gets a copy of one of them, usually admin, because admin is what the setup wizard offers first. The file is a bearer token. There is no password on top of it and no device confirmation behind it. Possession is authority.
That design is fine until the copies escape. On August 7, BTCPay Server updated an advisory telling every operator to move to version 2.4.2 immediately: an unauthenticated attacker could pull the LND macaroon files straight out of a BTCPay instance. The advisory named victims. Foundation, the hardware wallet maker, and Citadel21 had nodes swept and channels force-closed.
Then on September 9 Alby Hub confirmed a critical flaw in every version from 1.7.0 through 1.18.5. If the management interface was reachable from the internet, an attacker could take over the wallet and send funds. Alby says at least one user was hit. Two days earlier the project had quietly corrected its docs to admit that the Hub listens on all network interfaces, not just localhost, and changed its Docker example to publish the port to localhost only. Plenty of operators had read the old docs and forwarded the port so the phone app would work from the office.
Different bugs, same failure class. A credential with full node control sat somewhere the internet could reach.
Inventory where the copies went
Before you rotate anything, write down every place a macaroon has ever lived. Be honest; the list is longer than you expect. The phone wallet you paired with a QR code (Zeus, Alby, or the Umbrel app). BTCPay or any other payment processor. Any Telegram or Nostr tip bot you wired up. The ThunderHub or Ride The Lightning dashboard you spun up for monitoring. That rebalancing script running on a VPS somewhere. The lndconnect string you pasted into a chat to get help. The full node backup you dropped into cloud storage. Every one of those is a live key until the node is told otherwise.
Close the front door first
Rotation is pointless if the same door stays open, so check exposure before you touch the files. On your router, list every port forward and delete anything pointing at the node's REST port (8080), gRPC port (10009), or a web dashboard. Watching Bitcoin Core's port 8333 is fine; that is a service you chose to publish. A management interface is not. If you run Docker, confirm the compose file publishes management ports as 127.0.0.1:8080:8080 rather than 8080:8080. Check any reverse proxy or tunnel you set up for convenience and forgot.
Remote access should go through a private network, not a public port. Tailscale or plain WireGuard puts your phone and your node on the same private address space with nothing listening on the public side. Umbrel and Start9 both ship Tor access for the same reason: an onion address is reachable only by someone who has it, and nobody can port-scan their way to it.
Rotate in ten minutes
Once the door is shut, invalidate everything. LND's own macaroon documentation spells out the mechanism: the node checks for its three macaroon files at startup and, if they are missing, mints a new root key and regenerates them. Deleting the macaroons.db file invalidates every macaroon ever derived from the old key, including the ones you forgot about. A step-by-step rotation walkthrough for Umbrel written after the BTCPay advisory follows exactly that path.
1. Stop every app that talks to the node (BTCPay, dashboards, bots), then stop the Lightning node itself.
2. In the LND data directory (on Umbrel: app-data/lightning/data/lnd/data/chain/bitcoin/mainnet), delete every *.macaroon file and macaroons.db. Touch nothing else. wallet.db and channel.db are your funds and your channels.
3. Start the node. Confirm the three default macaroons reappear with fresh timestamps.
4. Start the dependent apps one at a time and reconnect each with the new credential. Anything you skip simply stops working, which is the point: an app you did not deliberately reconnect no longer has access.
5. Log the date. Repeat every quarter and after any advisory that touches your stack.
Nothing here closes a channel or moves a satoshi. The node keeps its keys; it just stops honoring the old passes.
Bake the replacement smaller
Do not hand every app a fresh admin macaroon and call it done. LND can bake a macaroon limited to specific permissions:
```
lncli bakemacaroon --save_to invoice-only.macaroon invoices:read invoices:write
```
A tip bot needs to create and read invoices. It never needs offchain:write (send payments) or onchain:write (sweep the wallet). Give each consumer the smallest set of verbs it can function on, and the next leak from that app is a nuisance rather than a wipeout. Core Lightning users get the same discipline through runes, which carry their restrictions inside the token. Keep the unrestricted admin macaroon on the node and nowhere else.
Tomas and the tip bot
Tomas runs an Umbrel node from home and sells Lightning-priced merch through BTCPay. In early 2025 he wired a Telegram tip bot on a cheap VPS by pasting his admin macaroon into its config, then forgot the bot existed when the channel went quiet. He also forwarded port 8080 once so Zeus would connect from work.
He patched BTCPay in August and updated Alby Hub in September and felt current. But the VPS still holds a working admin macaroon, the port forward is still live, and the BTCPay advisory says an attacker may already have copied his files before the patch. Patching closed the leak. It did not revoke what had already leaked. Only rotation does that, and after rotation the bot gets an invoice-only macaroon and Zeus reaches the node over Tailscale instead of a public port.
Final thoughts
Lightning's operating model puts real money behind a bearer token, and every app you connect becomes a place that token can be stolen from. Patching a vulnerable manager stops future theft of the credential but says nothing about copies already taken. Rotation is the only step that ends the old passes, and it costs you ten minutes and a few reconnections. Scoping the replacements means the next leak is small. Your seed is safe on the signer; the node's authority is only as safe as the least careful thing holding a macaroon. Revoke first, then trust again on your own terms.
