BTCPay Server 2.4.4 Blocks a New LND Takeover Route—but Custom Nodes Still Need Attention

BTCPay Server has shipped another security-focused update after detecting automated probes against Bitcoin Lightning nodes whose operators manually reopened outside access.

The warning does not cover every BTCPay installation. The standard Docker deployment had already disabled public access to the Lightning APIs.

The immediate risk sits with custom setups that put LND back on the open internet.

According to BTCPay Server, bots have been repeatedly calling LND’s password-change endpoint. That method can be reached without an authorization macaroon while an LND wallet is still locked.

Older BTCPay-managed LND wallets also shared a default password. During the brief window after an LND restart and before BTCPay’s internal unlock process completes, an attacker who can reach that endpoint could try to set a new password first and request an administrator macaroon.

The distinction between the default deployment and a manually exposed node is crucial. BTCPay’s standard Docker configuration already keeps the Lightning APIs off the public internet, so the project’s warning is aimed at operators who independently restored that access through a custom reverse proxy or similar network rule.

BTCPay is urging administrators to install version 2.4.4, but the software update is only part of the response. Anyone who created an outside route to LND must also remove that exposure, because an application update cannot rewrite a separate proxy or firewall configuration controlled by the operator.

BTCPay warns bots are probing manually exposed LND nodes for a route to admin control. No successful takeover through this method has been reported.

Version 2.4.4 adds protections, but operators must also remove manually exposed LND routes.https://t.co/G5xTtf8oKo

— CryptoSlate (@CryptoSlate) September 13, 2026

Version 2.4.4 attacks that route in two places. New LND wallets receive unique random passwords, while older wallets using the shared credential are migrated and rotated.

BTCPay’s standard reverse proxy now blocks unauthenticated wallet-setup and unlock methods at the network edge.

The release also tightens permissions around invoices, API keys and server administration. BTCPay replaced the application container’s broader host access with a restricted interface that allows only a small set of approved administrative commands.

CryptoSlate reported that BTCPay had not identified a successful takeover through this newly observed restart-time route. The report describes a narrow opening on an exposed older configuration: after LND restarts but before BTCPay unlocks the wallet, an attacker could attempt to replace the password and then request an administrator macaroon.

That administrator credential is what turns a probing attempt into a serious control risk. The important boundary is still network reachability.

A node using BTCPay’s standard protected path is not in the same position as one whose operator has placed the affected LND methods behind a public custom route.

The report also separates this warning from a different LND incident disclosed in August. Standard on-chain wallets managed through BTCPay were not affected by that separate event. Keeping those incidents distinct matters because the immediate corrective action here is specific: close manually exposed Lightning access and update the server.

No confirmed takeover through the newly observed route is reassuring, but it is not a reason for operators to wait. The bots are already testing reachable servers, which means the vulnerable window is an active target rather than a theoretical configuration mistake discovered only in a laboratory.

I promise I am working on re-enabling outside access to LND and CLN (opt-in) for docker deployments.

Meanwhile, this release is packed with security hardening. Update recommended!

Boring releases will continue for a little while as we adapt our worfklows to AI… https://t.co/Be0gEw2OAi

— Nicolas Dorier (@NicolasDorier) September 8, 2026

BTCPay can secure the deployment path it controls. It cannot automatically fix an administrator’s independent reverse proxy or firewall rules.

Anyone who manually exposed LND must remove that route, update to 2.4.4 and audit how remote Lightning access is published.

The project says outside access to LND and Core Lightning will return as an explicit opt-in feature. Until that supported path is available, its instruction is direct: do not expose LND through a custom reverse proxy.

The practical lesson for self-hosting is straightforward. Control is valuable, but every exception to a secure default becomes the operator’s responsibility.

When bots are already knocking, “advanced configuration” is not protection by itself.

Join the conversation!

We have no tolerance for comments containing violence, racism, profanity, vulgarity, doxing, or discourteous behavior. If a comment is spam, instead of replying to it please click the icon below and to the right of that comment. Thank you for partnering with us to maintain fruitful conversation.