BTCPay Server confirmed on August 7 that a critical vulnerability was being actively exploited against live servers, letting unauthenticated attackers steal Lightning Network credentials and drain connected nodes. The flaw affects every version of the open-source Bitcoin payment processor released before 2.4.2, including its release candidates. The project has confirmed users lost funds but has not disclosed the total amount stolen or how many operators were affected. It has also withheld full technical detail while patching continues, promising a complete postmortem within days.
How Attackers Accessed LND Credentials
The vulnerability let unauthenticated remote attackers retrieve LND “.macaroon” files, the credential tokens that grant software control over a Lightning node and its funds, without requiring any login. With those files in hand, an attacker gained full administrative access to a node, could force-close its channels, and could withdraw balances at will. BTCPay founder Nicolas Dorier called it a critical vulnerability being actively exploited that could result in loss of funds, and urged operators to update immediately or take affected servers offline.
Version 2.4.2 upgrades standard deployments to LND 0.21.1 and automatically regenerates macaroon credentials. It also temporarily disables public access to the LND API on Docker-based deployments, blocking external wallets such as Zeus from connecting through a BTCPay Server domain or Tor onion address. Regular Lightning payments continue to function normally, and BTCPay said remote access will return once the setup is considered safe. The same release fixes a separate TOTP two-factor authentication bypass through Basic authentication, now disabled by default five minutes after account creation unless a user opts back in. The project has not confirmed whether that bypass was the specific route attackers used to obtain LND credentials.
Confirmed Victims and Recommended Actions
At least two operators have publicly confirmed losses. Hardware-wallet maker Foundation’s CEO Zach Herbert said the company’s Lightning node was drained overnight, with all channels force-closed and funds swept, while its BTCPay on-chain hot wallet remained untouched. Bitcoin publication Citadel21, run by the pseudonymous commentator hodlonaut, reported its Lightning node was also swept, though it held minimal funds at the time. Neither party disclosed exact loss figures.
BTCPay Server said its standard on-chain wallets, including hot wallets, are unaffected by the credential flaw, though funds held in LND’s own on-chain wallet remain exposed. Operators running LND behind BTCPay Server should update immediately to version 2.4.2. Anyone exposing LND through a reverse proxy, Tor service, forwarded port, or any route outside BTCPay must rotate credentials separately, since the update does not close independently managed access paths. Operators unable to update right away have been told to take affected LND deployments offline and review their nodes for unauthorized payments, unexpected channel closures, unfamiliar peers, or unexplained balance discrepancies.
Conclusion
BTCPay Server moved fast to contain a live exploit, patching within roughly a day of confirming active theft. But the absence of a disclosed loss total, combined with an unresolved question about whether a separate authentication bypass enabled the attack, leaves merchants and exchanges without a full picture of their exposure. Developers credited Sparrow Wallet creator Craig Raw with helping piece together what happened, underscoring that the flaw surfaced only after victims were already robbed rather than through routine security scanning. Until the promised postmortem arrives, any operator running LND behind BTCPay Server bears responsibility for verifying its own node security rather than waiting on official confirmation of scale.
Sources & Methodology
AAFX.IO reports market information using primary data, official announcements and clearly attributed reporting wherever available. Source links are included within the article when referenced.
