BTCPay restricts remote lightning network access after attackers stole funds

BTCPay Server temporarily restricts remote Lightning network access to prevent attackers from exploiting the vulnerability to steal funds.

BTCPay Server has temporarily blocked public remote connections to Lightning network nodes running Lightning Network Daemon (LND) after attackers used a critical vulnerability to obtain credentials and transfer funds. The project said lightning payments can still work normally, while they are working to make remote access secure again.

In a security-driven update, BTCPay Server announced that version 2.4.2 has installed LND 0.21.1 and automatically regenerates the "macaroon" credential file used to control LND in standard deployments. Operators are also urged to check their nodes for signs of intrusion, including unauthorized payments, unexpected channel closures, suspicious peers, and differences between recorded balances and actual balances on the chain or in the Lightning network.

Key Points

BTCPay Server 2.4.2 restricts public remote connections to LNDs in Docker deployments, preventing external wallets from connecting through BTCPay domain names or Tor onion addresses.

This update automatically installs LND 0.21.1 and regenerates LND macaroon credentials in a standard BTCPay installation.

Operators should monitor unauthorized payments, unexpected channel closures, unfamiliar nodes, and inconsistent balances for signs of theft of funds.

If the operator exposes the LND through its own reverse proxy, Tor service, port forwarding, or other means other than BTCPay, the credentials must be rotated separately.

Why BTCPay blocks remote LND access

BTCPay Server's security bulletin focuses on a specific failure mode: According to BTCPay, a critical vulnerability allows an unauthenticated remote attacker to obtain a macaroon credential file used to authorize control of an LND node. These credentials are essentially key material that allows a party to manage or act on behalf of a node. BTCPay warned that exposed credentials could allow attackers to control LND instances and transfer funds.

In order to reduce the attack surface during the launch of the fix, BTCPay temporarily restricted public remote connections to Lightning network nodes running LND software through BTCPay managed endpoints. BTCPay emphasized in its statement that the change prevents external wallets, including Zeus, from connecting through the BTCPay Server domain name or the Tor onion address in Docker deployments.

It is important for daily operators that BTCPay said that flash payments can still continue. This restriction is considered a temporary measure until the project party deems it safe to restore previous remote access capabilities.

What 2.4.2 Updates mean for operators

The fixes for BTCPay are available through version 2.4.2. The project stated that this version installs LND 0.21.1 in a standard BTCPay installation and automatically regenerates macaroon credentials. This automatic rotation is designed to address the core risk identified in the security bulletin: an attacker may continue to use credentials after obtaining them unless the underlying authorization artifact is replaced. By updating both the LND version and the credentials used for control, BTCPay effectively forces a reset of authorization status in typical deployments.

In addition to software changes, BTCPay also provides a targeted checklist for operators to verify whether an intrusion has occurred. The project recommends checking the following:

Unauthorized payments-this suggests that someone managed the node against the operator's intentions.

Unexpected channel closure-This may imply hostile channel management or forced routing behavior.

Unfamiliar peer node-This may indicate that an attacker has established a connection to the node.

The difference between the operator's expected amount and the on-chain or Lightning network balance.

Crucially, BTCPay also addresses a deployment reality: not all operators expose LNDs only through BTCPay's own routes. For users running their own reverse proxy, Tor service, forwarding port, or alternative access path, BTCPay says that installing updates does not close independently managed access paths. In these cases, the operator must expose separate rotation credentials for any LNDs other than BTCPay's control endpoints.

Publicly reported financial losses, undisclosed amounts

After the vulnerability and fixes entered public discussion, at least two operators reported losses related to the clearing of their lightning nodes, although neither disclosed the stolen amount. Foundation CEO Zach Herbert said the hardware wallet company's lightning nodes were cleared overnight. He later clarified that his Hot Wallet was not affected, but the Lightning Channel was closed and funds emptied-indicating that the intrusion was limited to Lightning Channel control and not the broader wallet infrastructure.

In addition, Bitcoin publication Citadel21 reported that its lightning node had been cleared. Similar to Herbert's comments, the publication also did not provide specific amounts of the losses. While the reports did not determine the scale of the incident among all BTCPay users, they did reinforce the actual meaning of the security bulletin: credential exposure could translate into actual control of Lightning funds, and the repair work needs to be carried out quickly and thoroughly.

Security incidents continue to target Bitcoin network infrastructure

The BTCPay incident is the latest in a series of recent security issues affecting popular Bitcoin products. Previous reports that vulnerabilities related to Coldcard hardware wallets have been confirmed to have caused more than $100 million in losses, highlighting that attacks are often targeted at software and infrastructure components built around Bitcoin, rather than the Bitcoin protocol itself. This model is important because it transfers risk from "Bitcoin as a network" to the systems people use to interact with it: wallets, node operators, payment servers, and bridge software that connects users to blockchain operations. In practice, this means that the most valuable defenses are often at the operational level-timely patching, correct rotation of vouchers, careful management of exposures, and continuous monitoring of abnormal behavior.

BTCPay's temporary restriction of remote access can be seen as another step of this operational defense model: while updates are rolled out and operators are hardening their settings, reducing inbound paths that can lead to credential abuse. Currently, the most important thing for BTCPay operators is to apply version 2.4.2 and verify its exposure path, and then audit their nodes based on the specific intrusion metrics listed by BTCPay. Readers should also pay attention to whether BTCPay will restore remote access functionality after determining that the residual risks for the relevant deployment type have been fully mitigated.