An exposed admin page is normally an authentication problem. In BTCPay Server before 2.4.2, the exposed object was a credential file for the Lightning Network Daemon. The difference matters because an LND admin macaroon is not a read-only API key. It can authorize wallet operations, including movement of funds.
BTCPay Server published an urgent advisory after external access to .macaroon credentials was identified. CVE-2026-119757 describes an unauthenticated file-disclosure flaw affecting versions before 2.4.2, including release candidates. The CVE record assigns CVSS v3.1 9.8 and CVSS v4.0 9.3. The vendor says the stolen-funds risk applies specifically to deployments that use LND.
The official Docker deployment generated an Nginx route that exposed the lnd_bitcoin container. The advisory and later hardening notes explain that LND provides unauthenticated WalletUnlocker and State interfaces while a wallet is locked. An external party could reach more than a static file endpoint. The misconfiguration turned the reverse proxy into the trust boundary controlling who could read the node's credential material.
Why the macaroon is the asset
LND macaroons carry permissions. An admin macaroon can perform the broadest wallet actions, including creating invoices, managing channels, and moving funds. The exact damage depends on the node, its channels, its on-chain balance, and the permissions encoded in the credential. That uncertainty is why an unauthenticated read must be handled as a potential wallet compromise rather than a routine information leak.
The patched application is only one part of the response. A server can be upgraded while an attacker already possesses the old credential. The credential must be treated as live until the node's macaroon is regenerated or revoked and the old material is no longer accepted. BTCPay's advisory and follow-up hardening posts document the patching and credential-reset work required for affected operators.
The incident also shows why reverse-proxy templates deserve security review. A container can listen on a private service port and still become internet-facing if a generated route forwards it. Nginx configuration generated by a deployment tool is production configuration. It needs the same allowlist, authentication, and route tests as an application controller.
Immediate response for an affected operator
Take the BTCPay Server offline if the instance is old and the upstream LND endpoint is reachable from the internet. Upgrade to at least 2.4.2, then apply the current hardening release appropriate to the deployment. Confirm the proxy no longer exposes LND's REST or gRPC ports and that unauthenticated wallet setup or unlock routes are blocked.
Regenerate the LND admin macaroon according to the project's current procedure. Do not assume that restarting the container invalidates the old value. Check all derived credentials, backup files, automation, and external wallet connections that may have used the exposed macaroon. If the wallet password or seed material was also available to the attacker, the response may require moving funds and rebuilding the node.
Review LND and on-chain activity across the exposure window. Look for unauthorized invoices, channel opens or closes, address generation, payment attempts, and wallet-unlock events. BTCPay invoice logs are useful, but they are not a complete record of direct LND actions. Compare node and wallet evidence before concluding that no funds moved.
Detection and prevention
The strongest preventive control is to keep the LND API on a private listener and require an authenticated proxy for every administrative route. Deny access to the LND container from the internet by default. Add configuration tests that assert the public Nginx template contains no route to wallet-unlock, state, or macaroon paths.
Treat a macaroon file as a secret with an owner, an issuance record, and a revocation procedure. Separate payment-processing credentials from node-administration credentials wherever the deployment allows it. Rotate credentials when a reverse-proxy rule changes, not only when the application version changes.
This is a useful case for security teams because it replaces a vague warning about exposed services with a concrete chain: public proxy route, LND endpoint, macaroon file, wallet authority. The chain is short. The defensive decision should be equally direct.