BTCPay Server Flaw Is Actively Draining Merchant Lightning Nodes
BTCPay Server has issued an urgent security warning after attackers began exploiting a vulnerability affecting deployments connected to LND, allowing them to obtain sensitive authentication credentials and drain funds held in Lightning nodes.
Summary:
- Attackers are actively exploiting vulnerable BTCPay Server deployments using LND.
- The flaw can expose powerful LND macaroon credentials and allow funds to be drained.
- Foundation and Citadel21 are among the reported victims.
- BTCPay Server says operators should install v2.4.2 immediately or take servers offline.
The project is telling merchants and self-hosted operators to upgrade immediately to version 2.4.2 or shut down affected servers until they can patch, as confirmed losses continue to emerge and no aggregate figure has yet been disclosed.
The exploit targets the credentials controlling LND
The critical issue is not described as a weakness in Bitcoin or the Lightning protocol itself. Instead, it affects the infrastructure linking BTCPay Server to an LND node.
LND uses files known as macaroons to authorize software to perform specific actions. BTCPay’s own documentation explains that an admin.macaroon can provide broad permissions to a connected application, while operators can also create more restricted credentials containing only the permissions BTCPay needs.
In the actively exploited scenario, attackers are reportedly able to retrieve sensitive macaroon files remotely from vulnerable BTCPay deployments. If the stolen credential carries sufficient privileges, the attacker can effectively impersonate an authorized application and instruct the Lightning node to move funds.
That makes the severity substantially greater than a conventional information disclosure bug. Access to a high-privilege LND macaroon can translate directly into control over payment channels and node liquidity.
The affected stack can be understood in four layers:
- BTCPay Server: The merchant-facing payment application exposed to the vulnerability.
- LND: The Lightning implementation connected to the BTCPay deployment.
- Macaroons: Authentication credentials defining what connected applications may do.
- Lightning liquidity: Bitcoin held in channels or otherwise controlled through the node and potentially exposed when privileged credentials are stolen.
BTCPay Server’s standard Docker deployments can run LND alongside the payment server, and its documentation identifies the LND data directory and macaroon-based authentication model used by the integration.
Why stealing a macaroon can be as serious as stealing a password
A macaroon is not simply a login token for viewing an account.
LND uses macaroons as capability-based credentials. Different macaroons can grant narrowly defined permissions, but an administrator-level credential may authorize sensitive node operations.
That distinction explains why credential scope is central to the incident. BTCPay’s documentation explicitly recommends that operators who connect external nodes can create a custom macaroon limited to permissions such as reading node information, managing invoices and reading on-chain information instead of automatically providing unrestricted administrator access.
When an exposed application holds a credential with wider permissions than it actually needs, a vulnerability in that application can become a vulnerability in the entire Lightning wallet.
The security failure therefore has two components: the initial BTCPay exploit and the authority granted to the credential that can be extracted.
This is an important operational lesson for self-hosted Bitcoin infrastructure. Running services on your own hardware removes custodial dependence, but it does not remove application security risk. A merchant may hold its own keys while still exposing signing or payment authority through software credentials.
Foundation and Citadel21 report losses
Foundation, the company behind the Passport Bitcoin hardware wallet, is among the confirmed victims, according to reporting cited in the incident disclosures. Its Lightning node was compromised and drained, stated the CEO Zach Herbert in X.
Bitcoin publication Citadel21 has also reported being affected.
The incidents indicate that exploitation was already occurring before the vulnerability became widely known, which changes the appropriate response for operators. This is no longer a theoretical weakness that can be patched during a routine maintenance window.
A security issue being actively exploited requires administrators to assume that publicly reachable vulnerable instances may already have been scanned or compromised.
BTCPay has therefore advised users who cannot upgrade immediately to shut down their servers rather than leave vulnerable infrastructure online.
No verified industry-wide loss estimate has been published. That absence matters because confirmed victims do not reveal how broadly automated exploitation has spread across merchant deployments.
On-chain Bitcoin wallets appear to be outside the main attack path
Current reporting indicates that the exploit specifically threatens funds controlled through affected LND instances rather than standard Bitcoin wallets connected to BTCPay Server.
That boundary is technically plausible because Lightning nodes maintain their own operational credentials and channel state.
Compromising authorization to LND does not automatically provide access to every unrelated hardware wallet or Bitcoin private key used by a merchant.
Operators should nevertheless avoid interpreting “on-chain wallets unaffected” as proof that their individual deployment is safe. The consequences depend on architecture, credential permissions and whether secrets were reused or stored together.
A compromised server should be treated as an infrastructure compromise, not merely as a single leaked file.
Version 2.4.2 becomes an emergency security update
BTCPay Server’s response is straightforward: upgrade to version 2.4.2 immediately.
Operators unable to patch should take affected servers offline until they can do so. Public reports carrying the project’s warning say the vulnerability is being actively exploited and can result in financial loss.
The project’s public release history shows BTCPay Server 2.4.0 was released in late June, meaning the vulnerable installations include relatively recent infrastructure rather than only abandoned legacy servers.
Applying the patch is only the first response if a server may already have been exposed.
Operators should also treat previously stored LND credentials as potentially compromised. Rotating macaroons limits an attacker’s ability to continue using credentials collected before the software update, while moving remaining funds to fresh secure destinations can reduce residual exposure in cases where compromise is suspected.
Those post-incident actions are especially important because patching the vulnerability closes the entry point but does not inherently revoke authentication material an attacker may already possess.
The incident exposes a trade-off in self-hosted payments
BTCPay Server has become widely used because it allows merchants to accept Bitcoin without depending on a conventional payment processor. Its open-source architecture gives operators direct control over their payment infrastructure and can integrate both on-chain Bitcoin and Lightning.
That sovereignty transfers security responsibility to the operator.
A hosted processor centralizes risk at one company. A self-hosted merchant distributes that risk across individual installations, which makes mass theft harder through one custodial wallet but creates thousands of independently maintained internet-facing servers.
Security therefore depends on patch discipline, credential isolation and configuration quality as much as private-key ownership.
The current exploit is a clear example. Attackers did not need to compromise Bitcoin consensus or break Lightning cryptography.
They targeted the application layer through which businesses operate their nodes.
What operators should watch next
The next disclosure that matters is the technical advisory explaining exactly which BTCPay Server versions and configurations are vulnerable, how the credential files became remotely accessible and whether exploitation leaves reliable forensic indicators.
Loss estimates will also determine the scale of the event. Foundation and Citadel21 establish that real theft occurred, but they do not indicate whether attackers compromised a handful of high-value instances or conducted broad automated scanning across the BTCPay ecosystem.
The Bitcoin Red Team’s role also deserves attention. The volunteer initiative has recently been conducting large-scale security reviews across hundreds of Bitcoin-related open-source repositories, with public reports describing thousands of potential findings that still require validation. The BTCPay disclosure illustrates the value of separating reproducible, actively exploited vulnerabilities from automated findings that have not yet been confirmed.
The information presented in this article is intended for informational purposes only and should not be interpreted as financial, investment, or trading advice. Coinspress.com does not promote or advocate for any particular investment strategy, asset, or cryptocurrency project. Cryptocurrency markets are highly volatile and unpredictable – always perform your own research and seek guidance from a qualified financial professional before making any investment decisions.
Kosta Gushterov
Reporter at CoinsPress
Kosta has reported on cryptocurrency markets and blockchain infrastructure since 2020, bringing over six years of hands-on experience in the crypto industry built through daily tracking of markets, trends, and emerging blockchain developments. Specializing in Bitcoin on-chain analysis, institutional ETF flows, and digital asset price action, his work has been cited by other news agencies and consistently covers market developments with a focus on data-driven reporting across Bitcoin, Ethereum, Solana, and XRP. Over the years, Kosta has contributed to multiple crypto media outlets in different regions, authoring over 6,000 articles across the sector. His reporting spans cryptocurrency markets and the broader fintech industry, tracking not only price action but also the technological and regulatory forces shaping the ecosystem. To support his analysis, Kosta actively leverages on-chain data and metrics from leading platforms such as Santiment, Glassnode, and CryptoQuant, enabling deeper, evidence-based market insights. He believes in the power of transparency and the data that underpins the blockchain ecosystem. His academic background in Marketing Management from Denmark further complements his analytical approach, adding a strong understanding of communication strategy and content positioning to his work.
