BTCPay Server Vulnerability Is Being Actively Exploited to Drain LND Lightning Nodes

BTCPay Server has released an emergency security update after confirming that a critical vulnerability is being actively exploited against installations using LND. Attackers have been able to compromise BTCPay Server instances, obtain credentials used to control connected Lightning nodes, and move funds out of affected wallets. Merchants running BTCPay Server with LND should update to version 2.4.2 immediately. If an affected installation cannot be updated, the project recommends taking the server offline.

The incident is particularly serious because BTCPay Server is normally deployed directly alongside the merchant’s own Bitcoin and Lightning infrastructure. There is no custodial payment processor sitting between the merchant and the funds. That architecture gives operators control over their payments, but it also means a compromise of the payment server can become a compromise of the wallet infrastructure connected to it.

BTCPay Server published version 2.4.2 on August 7, 2026, explicitly stating that it contains a fix for a critical vulnerability that was already being exploited. The project also recommends that integrators update NBXplorer to version 2.6.10.

The incident is still developing, and the full extent of the losses has not been publicly established. Reports have identified Foundation among organizations affected, while other Lightning operators have temporarily disabled Lightning functionality while investigating their infrastructure. Foundation’s own documentation confirms that it operates a self-hosted BTCPay Server for Bitcoin payments, making it a directly relevant example of the type of deployment exposed by the incident.

What happened

The vulnerability is in BTCPay Server’s authentication layer rather than in the Lightning Network protocol itself. The affected component is the Greenfield API, BTCPay Server’s REST API for programmatic management of stores, invoices, wallets, Lightning functionality and other server operations. Greenfield supports two authentication mechanisms: API keys and HTTP Basic authentication. BTCPay’s documentation recommends API keys for integrations because they can be restricted to specific permissions, while Basic authentication is much broader.

The security problem was found in the way BTCPay handled accounts protected by two-factor authentication. A patch merged on August 4 shows the underlying mistake clearly. The BasicAuthenticationHandler was intended to prevent Basic authentication from bypassing multi-factor authentication, but the code checked whether the account had a FIDO2 credential. That condition did not cover users who had enabled authenticator-based TOTP 2FA without registering a FIDO2 credential.

As a result, an account protected by TOTP could authenticate to the Greenfield API with its username and password through Basic authentication without completing the second factor. The web interface itself correctly required 2FA, but the API authentication path did not enforce the same requirement. The patch replaced the narrower credential check with IsTwoFactorEnabledAsync(user), closing the gap. This was not a case where an attacker simply bypassed the BTCPay login page. The vulnerable path was an API authentication mechanism that operated differently from the normal web login flow.

BTCPay subsequently made another security-related change in pull request #7492. Greenfield Basic authentication is now disabled by default five minutes after an account is created, unless the user explicitly enables it. The project described this as a way to reduce the potential impact of bugs in the Basic authentication mechanism.

Why a BTCPay authentication bug can become a Lightning wallet problem

The most important technical detail in this incident is the boundary between BTCPay Server and LND. BTCPay is a payment processor, but when it is deployed with an internal Lightning node, it also acts as the management layer for that node. BTCPay’s documentation states that an internal Lightning node can be used by stores on the same self-hosted server. It supports LND, Core Lightning and Eclair.

LND itself uses macaroons for API authentication. A macaroon is a bearer-style authorization credential that can carry permissions and restrictions. In a typical BTCPay deployment, the application needs access to an LND macaroon so that it can perform Lightning operations on behalf of the merchant.

BTCPay’s own Lightning documentation notes that the LND admin.macaroon can be used to authenticate to the node and that BTCPay requires access to a macaroon to interact with LND. The documentation also identifies the LND data directory used by the standard Docker deployment and explains how macaroon credentials are stored there.

This creates an important trust relationship:

BTCPay authentication → BTCPay privileges → access to Lightning configuration and credentials → LND control → ability to move Lightning funds.

The security boundary is therefore much wider than the BTCPay web interface. An attacker who obtains sufficient privileges on the BTCPay server does not necessarily need to break LND cryptography. LND can be perfectly secure while the application sitting in front of it is compromised. If the attacker obtains a credential with enough authority to control the node, the cryptographic protections inside LND do not stop legitimate authenticated API requests made with that credential.

That is why describing this simply as an “LND vulnerability” would be misleading. The available technical evidence points to BTCPay’s authentication and authorization layer as the initial software flaw. LND becomes the target because BTCPay is trusted to operate the Lightning node.

The role of the Greenfield API

Greenfield is not a cosmetic interface. It exposes functionality that allows applications to automate BTCPay. The official API documentation lists operations involving stores, wallets, Lightning nodes, invoices, payouts and other payment functions. Authentication through an API key can be restricted to specific permissions, whereas Basic authentication implicitly provides unrestricted permission in the API model.

That difference is central to understanding the severity of the bug. A properly scoped API key might allow an ecommerce application to create invoices but have no authority to modify server settings or perform unrelated wallet operations. BTCPay explicitly recommends that integrations use narrowly scoped API keys rather than handing applications a user’s password.

Basic authentication, by contrast, authenticates the user account itself. The Greenfield API documentation states that Basic authentication provides the unrestricted permission context. That means a flaw that converts a password-only Basic-authenticated request into an authenticated API session is considerably more serious than a bug affecting a single low-privilege API endpoint.

The vulnerable logic was therefore dangerous because the authentication failure was occurring at the boundary between identity verification and authorization.

The normal web login flow understood that a TOTP-protected account required a second factor. The Greenfield Basic authentication handler made a different determination based on the presence of FIDO2 credentials. An account could therefore be protected by TOTP in the user interface while still being reachable through the API using only the password.

The patch is small, but the security consequence was large. The vulnerable code was effectively asking the wrong security question. It was checking whether a FIDO2 credential existed rather than whether two-factor authentication was enabled for the account.

How the attack reaches the Lightning wallet

Public reporting has described attackers obtaining Lightning credentials from compromised BTCPay deployments and using them to drain affected LND nodes. The precise operational details of the attacks are still limited, and BTCPay has not published a complete attacker playbook. It would therefore be inappropriate to invent a precise exploit chain beyond what the available evidence establishes.

What can be established technically is the relationship between the components. BTCPay’s LND integration requires access to macaroon credentials. The project’s documentation identifies admin.macaroon as a credential used for LND access and explains where these credentials reside in common deployments. BTCPay also exposes Lightning functionality through its management interfaces.

A macaroon is not a password that merely identifies a user. It is an authorization credential accepted by LND. Depending on the macaroon’s permissions, possession of it can allow an application to perform Lightning operations.

That is why credential theft is particularly dangerous in this environment. Once an attacker obtains a sufficiently privileged LND macaroon, they do not have to recover the merchant’s seed phrase or break Bitcoin’s cryptography. They can authenticate to the Lightning node using the credential that the node already trusts.

This is also why the incident should not be confused with a Bitcoin private-key compromise. Lightning nodes are different from ordinary Bitcoin cold-storage wallets. LND manages active Lightning channels and associated funds using keys that must remain available to the node. BTCPay’s own deployment documentation explicitly warns that running a Lightning daemon requires a hot wallet on the BTCPay server and that Bitcoin committed to or received through Lightning channels is controlled by private keys located on that server. That architectural fact turns a remote application compromise into a potential financial-loss event.

Why 2FA did not save affected accounts

Two-factor authentication is supposed to prevent a stolen or guessed password from being sufficient to access an account. The BTCPay vulnerability broke that assumption for one API authentication path. According to the patch description, users who had enabled authenticator-based TOTP without a FIDO2 credential could access the Greenfield API using Basic authentication with only their email address and password. The normal user interface still enforced the second factor, which meant that the same account could behave differently depending on whether authentication occurred through the web interface or the API.

This is a classic example of why security reviews cannot stop at the login screen. An application may have a perfectly functioning MFA prompt while still exposing another authentication route that does not enforce MFA. From an attacker’s perspective, the weaker path is the real login system.

The problem was particularly relevant because Basic authentication is designed for programmatic access. An attacker does not need to reproduce browser behavior or defeat a JavaScript-based MFA flow if the API accepts the same account credentials through a separate authentication handler. The subsequent decision to disable Greenfield Basic authentication by default after five minutes further reinforces the project’s assessment that Basic authentication represented unnecessary attack surface.

Why the Lightning credentials matter more than the BTCPay account

It is tempting to think of the BTCPay account and the Lightning wallet as separate security domains. In a properly configured architecture they should be treated as separate trust zones, but in an integrated self-hosted deployment there is an intentional bridge between them. BTCPay needs to communicate with LND. That communication requires credentials. Those credentials have to exist somewhere the BTCPay process can access them, whether the node is local or externally connected.

The official documentation shows that BTCPay can use an LND macaroon file directly and that the standard Docker installation stores LND data under a Docker volume. BTCPay can also connect to external Lightning nodes using credentials supplied through its configuration.

The security implication is straightforward: compromising the application that has access to those credentials can compromise the service those credentials control. For merchants, this is the key lesson from the incident. The web application, payment processor, Lightning daemon and wallet should not be considered interchangeable components, but they also cannot be treated as independent once credentials cross those boundaries.

BTCPay 2.4.2 is the emergency fix

BTCPay Server released version 2.4.2 on August 7 and explicitly described it as a fix for a critical vulnerability that was already being actively exploited. The release notes say users should update as quickly as possible and recommend that integrators also update NBXplorer to 2.6.10.

The release also changes Greenfield authentication behavior. Basic authentication is disabled by default five minutes after account creation, while an explicit opt-in remains available. The release notes describe this as a breaking change, although the project says it is not aware of users being affected because API-key authentication is generally used.

The patch also fixes the TOTP bypass in Greenfield Basic authentication. The underlying code change is straightforward: instead of checking for a particular type of second-factor credential, BTCPay now checks whether two-factor authentication is actually enabled for the account.

That is an important security improvement because authentication policy should be based on the account’s effective security state, not on the presence of one particular credential type.

What BTCPay operators should do now

Operators running BTCPay Server should treat this as an incident-response situation rather than an ordinary software upgrade. The first priority is to determine whether the server is running a vulnerable version and update to BTCPay Server 2.4.2. Integrators should also update NBXplorer to 2.6.10, as recommended by the project.

If immediate patching is not possible, BTCPay’s release notice recommends taking the server offline. That is a substantially safer temporary measure than leaving a potentially compromised payment server publicly reachable.

Operators should then assume that Lightning credentials may have been exposed if the instance was vulnerable and accessible during the exploitation window. Updating the application alone should not be treated as proof that previously exposed credentials are safe. LND credentials should be reviewed and rotated or regenerated according to the deployment’s recovery procedure, particularly where privileged macaroons were accessible to the compromised application.

BTCPay’s documentation explains that deleting the relevant LND macaroons and restarting LND invalidates the previous macaroons in standard deployments, although doing this affects applications that depend on those credentials and therefore needs to be planned carefully.

Operators should also review Lightning transactions and channel activity for unexpected payments, withdrawals, channel operations or other activity that occurred while the server could have been exposed. The exact investigation procedure will depend on whether the installation uses an internal LND node, an external LND node, Docker, a custom deployment or additional Lightning management software.

The same review should be performed against BTCPay authentication logs and server logs. Unexpected API requests, unfamiliar IP addresses, unusual authentication events and unexplained access to server or Lightning configuration should be treated as potential indicators of compromise.

If funds have already moved, preserving the relevant logs and transaction information before rebuilding or deleting components is important. The Bitcoin blockchain provides a permanent record of on-chain transactions, while Lightning activity may require reconstruction from node logs, channel data and cooperating peers.

Merchants should not assume that only large nodes are at risk

The potential impact does not depend solely on the size of a merchant’s business. A Lightning node is effectively a hot wallet. The amount at risk is therefore the amount the operator has chosen to keep available on the node, including funds committed to channels and funds held by the node for payment processing.

BTCPay’s documentation explicitly warns operators about this. Lightning requires keys to remain available on the server because the node must be able to manage its channels and process payments.

That makes the incident different from a conventional ecommerce application vulnerability where the primary consequences might be stolen customer information or unauthorized orders.

Here, successful compromise can cross directly into financial operations.

A merchant might have a well-secured Bitcoin cold-storage setup and still suffer a Lightning loss because the Lightning wallet is intentionally kept online. The cold wallet’s security does not protect funds that have already been moved into an exposed Lightning node.

The incident also exposes a broader API security problem

The technical lesson extends beyond BTCPay. Authentication systems often accumulate multiple paths over time: browser login, API keys, Basic authentication, OAuth, single sign-on, hardware-backed credentials and automation interfaces. Each path may have been implemented by different components and may make slightly different assumptions about the user’s security state.

That creates opportunities for what security engineers sometimes call authentication policy inconsistency. In this case, the browser login correctly recognized TOTP as a second factor. The Greenfield Basic authentication path effectively recognized FIDO2 credentials instead. Both checks were individually plausible, but together they created a bypass.

The safer design is to establish a single authoritative account-security state and make every authentication mechanism consult it.

BTCPay’s patch does exactly that by moving the decision from a credential-specific check to the account-level IsTwoFactorEnabledAsync(user) check.

The second lesson is about API privilege. BTCPay’s documentation already recommends API keys with only the permissions required by an integration. That model limits the blast radius if an individual integration credential is compromised. Basic authentication does not provide the same granularity because it authenticates as the user rather than as a narrowly scoped application credential.

For payment infrastructure, that difference is especially important. An API credential that can create invoices is one thing. A credential that can access wallet functionality or manage a Lightning node is another.

What is known, and what is not

The confirmed facts are enough to establish a serious incident without filling the remaining gaps with speculation. BTCPay Server released 2.4.2 after confirming active exploitation of a critical vulnerability. The vulnerable area was Greenfield Basic authentication. The underlying flaw allowed TOTP-protected accounts to bypass the second factor through the Basic-authenticated Greenfield API when the account had TOTP enabled but no FIDO2 credential. BTCPay subsequently changed the authentication behavior and disabled Greenfield Basic authentication by default after five minutes for newly created accounts.

BTCPay’s architecture makes the issue more consequential for deployments using LND because the payment processor can hold or access credentials required to operate the Lightning node. BTCPay’s documentation confirms its use of LND macaroons and the location of LND credentials in common deployments.

The exploitation has resulted in real-world fund losses according to reporting surrounding the incident, including a reported impact on Foundation. However, a definitive aggregate loss figure has not been established publicly, and the complete list of affected operators is not yet known.

The public technical record also does not justify claiming that every BTCPay Server installation was vulnerable in exactly the same way. Exposure depends on configuration, authentication settings, connected Lightning infrastructure and the privileges available to the compromised account.

The immediate takeaway

This incident is a reminder that self-hosting changes where the security responsibility sits.

BTCPay Server removes the need to hand payment processing to a centralized third party, but the merchant becomes responsible for securing the server, authentication system, APIs, Lightning credentials and wallet infrastructure. A vulnerability in one layer can therefore have consequences far beyond the application itself.

For operators running LND, the appropriate response is to update to BTCPay Server 2.4.2, update NBXplorer to 2.6.10 where applicable, and investigate the associated Lightning credentials rather than assuming that a software upgrade alone proves the node is clean. If the server cannot be patched immediately, it should be taken offline as BTCPay recommends.

The most important technical point is equally simple: the vulnerability was in BTCPay Server’s authentication path, but the valuable target was the Lightning infrastructure behind it.

That is what turned an API authentication bypass into a cryptocurrency theft incident.