BTCPay Limits Remote Lightning Access After Attackers Steal Funds

BTCPay Server has temporarily blocked public remote connections to Lightning Network nodes running the Lightning Network Daemon (LND) after attackers exploited a critical vulnerability to obtain credentials and move funds. The project says Lightning payments can still proceed, while it works to make remote access safe again.

In a security-driven update, BTCPay Server announced that version 2.4.2 installs LND version 0.21.1 and automatically regenerates the “macaroon” credential files used to control LND on standard deployments. Operators are also urged to inspect their nodes for signs of compromise, including unauthorized payments, unexpected channel closures, suspicious peers, and mismatches between recorded balances and what’s actually present onchain or in Lightning.

Key takeaways

• BTCPay Server 2.4.2 restricts public remote connections to LND on Docker deployments, preventing external wallets from connecting via BTCPay domains or Tor onion addresses.
• The update automatically installs LND 0.21.1 and regenerates LND macaroon credentials on standard BTCPay installations.
• Operators should monitor for unauthorized payments, unexpected channel closures, unfamiliar peers, and balance discrepancies as indicators of theft.
• If an operator exposes LND through their own reverse proxy, Tor service, port forwarding, or other routes outside BTCPay, credentials must be rotated separately.

Why BTCPay moved to block remote LND access

BTCPay Server’s advisory centers on a specific failure mode: a critical vulnerability that, according to BTCPay, allowed an unauthenticated remote attacker to obtain the macaroon credential files that authorize control of an LND node.

Those credentials are effectively the key material that lets a party manage or act on behalf of the node. BTCPay warned that exposed credentials could enable attackers to take control of the LND instance and move funds.

To reduce the attack surface while remediation is rolled out, BTCPay temporarily restricted public remote connections to Lightning nodes running LND software through BTCPay-managed endpoints. In its statement, BTCPay highlighted that the change blocks external wallets—including Zeus—from connecting through a BTCPay Server domain or a Tor onion address in Docker deployments.

Importantly for day-to-day operators, BTCPay said Lightning payments can continue. The restriction is framed as a stopgap measure until the project believes it is safe to restore the prior remote-access functionality.

What the 2.4.2 update changes for operators

BTCPay’s fix is delivered through version 2.4.2. The project says this release installs LND version 0.21.1 and automatically regenerates macaroon credentials on standard BTCPay installations.

That automatic rotation is designed to address the core risk identified in the security advisory: attackers who acquired credentials could use them after the fact unless the underlying authorization artifacts are replaced. By updating both the LND version and the credentials used for control, BTCPay is effectively forcing the authorization state to reset for typical deployments.

Alongside the software changes, BTCPay provided a targeted checklist for operators to validate that compromise has not occurred. The project advised checking for:

• Unauthorized payments, which would indicate someone managed the node outside the operator’s intent.
• Unexpected channel closures, which can signal hostile channel management or forced routing behavior.
• Unfamiliar peers, which may reveal that an attacker established connections to the node.
• Discrepancies between what operators expect and what appears in their onchain or Lightning balances.

Crucially, BTCPay also addressed a deployment reality: not every operator exposes LND only through BTCPay’s own routing. For those running their own reverse proxy, Tor service, forwarded port, or alternative access path, BTCPay said installing the update does not close access routes managed independently. In those cases, operators must rotate credentials separately for any LND exposure outside BTCPay-controlled endpoints.

Public reports of losses, without disclosed amounts

After the vulnerability and remediation became part of the public conversation, at least two operators reported losses linked to their Lightning nodes being swept, though neither disclosed the amount taken.

Foundation CEO Zach Herbert stated that the hardware-wallet company’s Lightning node was drained overnight. He later clarified that its hot wallet was unaffected, while its Lightning channels were closed and the funds were swept—suggesting the compromise was confined to Lightning-channel controls rather than broader wallet infrastructure.

Separately, Bitcoin publication Citadel21 reported that its Lightning node had been swept. Like Herbert’s comments, the publication did not provide figures for how much was lost.

While the reports do not establish the scale of the incident across all BTCPay users, they do reinforce the advisory’s practical implication: credential exposure can translate into actionable control over Lightning funds, and remediation needs to happen quickly and thoroughly.

Security incidents keep targeting Bitcoin infrastructure around the network

BTCPay’s incident is the latest in a run of security problems affecting popular Bitcoin products. Earlier coverage from Cointelegraph highlighted a Coldcard hardware-wallet flaw associated with more than $100 million in confirmed losses, underscoring that the targets have tended to be software and infrastructure components built around Bitcoin—not the Bitcoin protocol itself.

This pattern matters because it shifts risk away from “Bitcoin as a network” and toward the systems people use to interact with it: wallets, node operators, payment servers, and bridging software between users and blockchain operations. In practice, that means the most valuable defenses are often operational—timely patching, correct credential rotation, careful exposure management, and continuous monitoring for anomalies.

BTCPay’s temporary restriction of remote access can be read as another step in that operational defense model: reduce inbound paths that could allow credential abuse, even as updates roll out and operators harden their setups.

For now, the most important thing for BTCPay operators is to apply version 2.4.2 and verify their exposure paths, then audit their nodes for the specific compromise indicators BTCPay listed. Readers should also watch for whether BTCPay restores remote-access features once it determines the remaining risk has been fully mitigated for the relevant deployment types.