BTCPay Server has suspended remote access to Lightning Network nodes after hackers exploited a critical vulnerability to steal authentication credentials known as macaroons, granting attackers unrestricted control over affected systems. At least two victims — Foundation, led by CEO Zach Herbert, and Bitcoin outlet Citadel21 — confirmed their Lightning nodes were fully drained overnight. Neither has disclosed loss figures. BTCPay released version 2.4.2 to patch the flaw and automatically rotate credentials for standard setups, though custom configurations require manual intervention. The breach follows a separate Coldcard wallet exploit tied to over $100 million in losses.
A Critical Flaw Exposes Lightning Infrastructure
BTCPay Server, one of the most widely used self-hosted payment processors in the Bitcoin ecosystem, has pulled the plug on public remote access to Lightning Network nodes after discovering that attackers had found a way to steal the digital keys that control them. The emergency measure follows confirmation that at least two node operators had their funds swept out overnight, in what security researchers are describing as a serious breach of Lightning Network Daemon (LND) infrastructure. At the center of the exploit are "macaroon" authentication files — specialized credential tokens that function much like a master key to an LND node. Whoever holds a node's macaroon effectively holds the node itself, with the ability to authorize payments, close channels, and move funds without further verification. Once attackers obtained these files, they had, in practice, the same level of control as the legitimate operator. The vulnerability specifically affected setups where third-party wallet applications — such as the mobile Lightning wallet Zeus — connected to nodes remotely through BTCPay Server's domain infrastructure or Tor onion addresses on Docker-based deployments. It was through this remote-access channel that the credential theft became possible.
BTCPay's Emergency Response
In response, BTCPay Server moved quickly to cut off the exposed pathway. The company has blocked remote wallet connections via its domains and onion addresses for Docker installations, while stressing that this is a containment measure rather than a full shutdown of functionality. Lightning payments themselves continue to process normally for affected node operators; it is only the remote-access feature — the mechanism that made the theft possible — that has been disabled. BTCPay has not committed to a firm timeline for restoring remote access, saying only that the feature will return once the company is confident the underlying security gap has been fully closed and validated.
The Fix: Version 2.4.2
To address the root cause, BTCPay released version 2.4.2, which bundles in LND version 0.21.1 and, critically, performs an automatic regeneration of macaroon credentials for standard installations. In effect, the update invalidates any stolen keys by issuing fresh ones — a straightforward but essential remediation for the majority of users running default configurations. However, the fix has limits. Node operators who route their LND traffic through custom reverse proxies, self-hosted Tor services, or independently configured port-forwarding setups outside BTCPay's default architecture will not benefit from the automatic credential rotation. For these operators, manual regeneration of macaroon files is required — and BTCPay has been explicit that its patch does not reach access pathways built outside its standard setup.
What Operators Should Be Watching For
BTCPay has urged all node operators, regardless of whether they believe they were affected, to conduct a thorough security review. Recommended checks include:
- Unusual or unauthorized payment activity
- Unexpected Lightning channel closures
- Unfamiliar peer connections to the node
- Discrepancies in onchain or Lightning wallet balances
The guidance reflects a broader reality of Lightning Network security: because channels are cryptographically bound to specific keys, a compromised macaroon can allow an attacker to force-close channels and claim funds well after the initial breach, making after-the-fact audits essential even for operators who see no immediate red flags.
Confirmed Casualties: Foundation and Citadel21
Two organizations have gone on record confirming they were hit. Zach Herbert, CEO of Foundation, disclosed that his company's Lightning node was completely emptied overnight. Herbert was careful to clarify that Foundation's hot wallet infrastructure — the systems holding the bulk of operational funds — remained secure and untouched by the intrusion. The damage, he said, was confined to the Lightning channels, which were forcibly closed by the attackers, who then withdrew the associated funds. Bitcoin-focused media outlet Citadel21 reported an identical outcome: its Lightning node was fully drained in the same manner. Neither Foundation nor Citadel21 has released a specific dollar figure for the losses, leaving the financial scope of the breach — at least at the level of individually confirmed victims — undisclosed. More significantly, the full extent of the incident across the broader BTCPay and LND ecosystem remains unknown. With Lightning nodes operated by individuals and businesses worldwide, and with BTCPay providing no public tally of affected users, the two confirmed cases may represent only a fraction of the actual damage.
A Second, Unrelated Blow to Bitcoin Infrastructure
The timing compounds the unease. This breach lands just weeks after a separate vulnerability tied to the Coldcard hardware wallet was linked to confirmed losses exceeding $100 million. BTCPay has been explicit that the two incidents are unconnected — different attack vectors, different systems, different root causes. Both, however, share a common thread: neither compromised Bitcoin's core protocol. Bitcoin's base-layer consensus mechanism remains untouched; the vulnerabilities lie squarely in the software and infrastructure layered on top of it — custodial and semi-custodial tooling, hardware wallet firmware, and node management systems. That distinction matters for how the market should interpret these events. Bitcoin's protocol-level security has not been called into question by either incident. What has been exposed, twice in quick succession, is the fragility of the surrounding ecosystem — the wallets, nodes, and interfaces that everyday users and businesses rely on to actually interact with the network.
Strategic Takeaways for Node Operators and Investors
For Lightning Network operators, the immediate priority is unambiguous: update to version 2.4.2 without delay, and for any non-standard configuration, manually rotate macaroon credentials rather than assuming the patch has already handled it. Delaying the update leaves stolen credentials — if any were obtained but not yet used — valid and exploitable. For businesses and institutions holding Bitcoin exposure through Lightning-based payment infrastructure, the episode is a reminder that custody risk and protocol risk are not the same thing. A business can be fully confident in Bitcoin's underlying security while still being exposed through the operational layer — node configuration, remote access permissions, and credential management. Diligence at that operational layer is not optional; it is where breaches of this kind actually occur. Broader market implications are, for now, likely to be contained. Neither incident touches custodial exchange balances or ETF-held Bitcoin, and total confirmed losses from this breach remain undisclosed and likely modest relative to the Coldcard exploit. But the cumulative effect of two infrastructure-layer breaches within a short window may prompt institutional users to accelerate scrutiny of self-custody and node-operation practices — a trend worth watching for anyone allocating to Bitcoin-adjacent infrastructure providers or evaluating counterparty risk in the sector. BTCPay's guidance to the wider community remains straightforward: patch immediately, audit thoroughly, and treat remote-access convenience as a feature to be re-enabled only once its security has been fully re-established.
- Log in to post comments