BTCPay Limits Remote Lightning Access After Reported Node Drains

BTCPay Server has taken a defensive step for Bitcoin Lightning users, temporarily blocking public remote connections to Lightning Network nodes running LND after attackers reportedly exploited a critical vulnerability to steal credentials and move funds.

The project said Lightning payments can still be processed, but external wallets—such as Zeus—will be unable to connect via a BTCPay Server domain or a Tor onion address in Docker-based deployments until BTCPay decides it is safe to re-enable that remote access pathway.

Key takeaways

• BTCPay Server has temporarily restricted public remote access to LND nodes in Docker deployments to reduce the chance of further credential misuse.
• Version 2.4.2 installs LND 0.21.1 and automatically regenerates Lightning “macaroon” credentials for standard BTCPay installations.
• Operators are urged to look for signs of compromise, including unauthorized payments, unexpected channel closures, unfamiliar peers, and mismatches between onchain/Lightning balances.
• Deployments that expose LND through routes outside BTCPay—such as a user-managed reverse proxy, Tor service, or forwarded ports—must rotate credentials separately.

Why BTCPay is limiting remote access

In a statement shared by BTCPay Server on X, the team said the restriction is designed to prevent external wallets from reaching affected Lightning nodes through BTCPay’s publicly exposed endpoints. The immediate concern is not the Lightning protocol itself, but how remote access can be abused when attackers gain control over the credentials that authorize actions on an LND node.

BTCPay emphasized that the change is intended to be temporary. It also indicated its plan is to bring remote access back once it determines it is safe—an important operational detail for service providers that rely on broad wallet connectivity for day-to-day payments.

What version 2.4.2 changes in LND authentication

BTCPay’s fix centers on credential rotation. According to the project’s security guidance, attackers were able to obtain “macaroon” credential files without proper authentication. Macaroons are the authorization artifacts LND uses to control access to node capabilities. If an attacker acquires them, the potential outcome is full take-over of the LND node and the ability to move funds.

BTCPay said version 2.4.2 addresses the issue by installing LND version 0.21.1 and automatically regenerating macaroon credentials on standard BTCPay setups. For operators, this is significant because it reduces the likelihood of lingering compromised credentials after an update—though it does not eliminate the need for active incident checks.

The project advised operators to verify whether compromise attempts occurred by reviewing several common indicators: unauthorized payments, unexpected channel closures, unfamiliar peers, and discrepancies between their records and either onchain or Lightning balances.

Actions operators must take beyond updating BTCPay

BTCPay’s instructions also draw an important line between what the software controls and what an operator configures. The team stated that installing the update does not automatically close access routes managed independently by the operator. If an LND node is exposed through other paths—such as a reverse proxy configured by the operator, a Tor service not run through BTCPay, or a forwarded port—then credential rotation may need to happen separately.

That distinction matters because it changes the practical remediation workflow. Updating BTCPay may fix the credential lifecycle for standard deployments, but it may not fully protect a node that is independently reachable. For operators, the key is to inventory how their LND node is reachable and ensure authorization material is rotated everywhere that the node can be accessed.

Reported impacts from operators

BTCPay’s warning is not theoretical. At least two operators publicly reported that their Lightning nodes were drained after the incident.

Foundation CEO Zach Herbert said the Lightning node associated with the hardware-wallet company’s setup was drained overnight. He later clarified that the company’s hot wallet was unaffected, while its Lightning channels were closed and funds were swept. The operators did not disclose the amount lost.

Bitcoin publication Citadel21 also reported that its Lightning node had been swept, without specifying the size of the loss.

While these reports are limited, they underline the risk that credential compromise can translate into direct fund movement via Lightning channels—reinforcing why BTCPay is restricting public remote access and why operators are being asked to check channel and peer activity closely.

Broader security implications for Bitcoin users

BTCPay’s incident comes amid a wider pattern of security problems affecting popular Bitcoin products. The BTCPay breach is described as part of the most recent wave of vulnerabilities impacting Bitcoin-adjacent tooling, following a Coldcard hardware-wallet flaw that was linked to more than $100 million in confirmed losses, as referenced in earlier coverage by Cointelegraph.

In other words, the underlying Bitcoin network is not the target; the failures occur in the surrounding systems—wallets, custody interfaces, and node management software—that users depend on to interact with the protocol.

For Lightning operators, the immediate next steps are clear: update to BTCPay Server version 2.4.2 (or apply the relevant fixes), verify that macaroon credentials are rotated as expected, and actively audit for unauthorized payments, unexpected channel behavior, unfamiliar peers, and balance mismatches. As BTCPay evaluates when to restore remote access, operators should also monitor how their own exposure routes outside BTCPay are configured—because those may determine whether the risk has truly been eliminated.