BTCPay Server has temporarily disabled public remote connections to Lightning Network Daemon (LND) nodes after attackers exploited a critical vulnerability to obtain authentication credentials and drain funds from at least two reported Lightning nodes.
The restriction affects Docker-based BTCPay Server deployments configured to let external Lightning wallets, including Zeus, reach an LND node through a BTCPay Server domain name or Tor onion address. Local Lightning payments remain available, and BTCPay Server said it will restore remote access after it determines the connection method is safe.
The move places a security barrier around a feature used by node operators who want to manage Lightning balances from a separate mobile or desktop wallet. It does not shut down Lightning functionality across BTCPay Server, but it removes a remote-management route that attackers used to reach exposed LND credential files.
Attackers accessed LND macaroon credentials
The vulnerability allowed an unauthenticated remote attacker to access LND “macaroons,” credential files that authorize applications and users to perform actions on a Lightning node. Depending on the permissions attached to a macaroon, an attacker could use it to control the node, send Lightning payments, alter channels, or move funds after channels are closed.
BTCPay Server released version 2.4.2, which installs LND version 0.21.1. On standard installations, the update also automatically regenerates macaroon credentials, invalidating the old files that may have been exposed through the vulnerable route.
The project did not disclose how many operators were affected or the total amount stolen. Two operators publicly reported losses. A user identified as Herbert said their Lightning node was emptied overnight, while the associated hot wallet was unaffected. The attacker closed Lightning channels and swept the resulting funds, according to the account.
Citadel21 separately said its Lightning node had been swept. Neither Herbert nor Citadel21 disclosed a loss amount.
Lightning channels hold funds in a shared onchain arrangement that can be closed cooperatively or unilaterally. An attacker with sufficiently powerful LND credentials could potentially force channels to close, then direct funds through the node’s available withdrawal paths. That makes the exposure particularly serious for operators who kept meaningful balances in a publicly reachable Lightning environment.
Update does not cover self-managed exposure routes
BTCPay Server urged affected operators to install version 2.4.2 and review their node activity for signs of compromise. The project specifically pointed to unauthorized payments, unexpected channel closures, unfamiliar peers, and discrepancies between internal records and onchain or Lightning balances.
The automatic credential regeneration applies to standard configurations, but operators who exposed LND through their own infrastructure face additional work. That includes node operators using a self-managed reverse proxy, a separate Tor service, port forwarding, or other externally managed connection routes.
Those operators need to rotate their LND credentials independently because the BTCPay Server update does not close access paths that exist outside its own configuration. A node could remain reachable through a manually configured route even after the software update has changed the credentials or disabled BTCPay Server’s public connection feature.
The incident underlines a practical difference between running a Lightning node for personal payments and operating one with remote-access conveniences enabled. Remote connectivity can make a node easier to use from external wallets, but it also expands the number of services, credentials, and network paths that must be secured. The temporary block limits that exposure while BTCPay Server addresses the underlying issue.
Operators with a suspected compromise would need to treat their Lightning node separately from other wallets connected to the same server. Herbert’s report that a hot wallet remained intact while Lightning channels were emptied illustrates that wallet separation can contain damage, even though it does not prevent theft from the affected node.
Security concerns extend beyond node software
The BTCPay Server event followed another reported security incident involving Bitcoin-related hardware wallet products, with more than $100 million in confirmed losses cited in the supplied account. That separate flaw reportedly involved weak private-key generation and affected more than 7,300 wallets, according to a researcher identified as Thorn.
The two events involve different technical failures. The LND case centers on stolen operational credentials from an exposed service, while the hardware-wallet issue concerns the generation of private keys. Neither allegation points to a weakness in Bitcoin’s base protocol; both concern the security of products and configurations used to hold or move Bitcoin.
That distinction has direct consequences for users. A secure blockchain cannot prevent theft when an attacker obtains valid credentials or when a wallet generates predictable keys. In such cases, transactions can appear valid on the network because they were authorized with credentials or keys that the attacker acquired.
The supplied account also cited more than $30 million in losses from violent crimes targeting digital-asset holders during the first six months of 2026. Physical coercion presents a separate threat from software exploitation, and no software update can address it. The combination of technical and physical risks has increased attention on how much value individuals keep immediately spendable and how much operational information they expose.
Operators face an immediate review period
For BTCPay Server users, the urgent task is narrower: update affected Docker deployments, identify any independent LND exposure routes, rotate credentials where required, and inspect Lightning and onchain activity for suspicious changes.
Temporarily disabling remote wallet connections may inconvenience operators who rely on applications such as Zeus, but it reduces the immediate attack surface while the project works toward a safer restoration. The reported thefts show why access to node credentials must be treated with the same care as access to funds themselves: in a Lightning setup, the line between the two can be very thin.
Worried about hacks like this? Learn essential wallet protection tips in this security guide to safeguard your funds.
Disclaimer: The content on this page is provided for general informational purposes only and does not represent the views or financial advice of Toobit. We make no guarantees regarding the accuracy or completeness of this information and shall not be held liable for any errors, omissions, or outcomes resulting from its use. Investing in digital assets involves risk; users should independently evaluate their financial situation and the risks involved. For further details, please consult our Terms of Service and Risk Disclosure.
