BTCPay Server Hot Wallet Thefts, Fixed in 2.4.2

TL;DR

• Attackers stole Bitcoin and Litecoin from the hot wallets of servers running BTCPay Server 2.4.1 or earlier, through the vulnerability fixed in 2.4.2 on August 7, 2026. The vendor disclosed the thefts on November 2, 2026.
• Every release before 2.4.2, including the 2.4.2 release candidates, is affected. The August attacks took over LND Lightning nodes; the November thefts drained the servers' on-chain hot wallets.
• The vendor rates the flaw critical and reports funds stolen in August and on November 1, 2026. No CVE is assigned, and the flaw is not in CISA's KEV catalog as of November 3, 2026.
• If you run 2.4.1 or earlier, move to a fresh server with a new wallet after sweeping your funds. Updating in place cannot remove access an attacker may already have gained. See "How do I fix it?".

Am I affected?

You are exposed when all of these hold:

• Your deployment runs BTCPay Server 2.4.1, released on July 23, 2026, or any earlier version. The vendor's advisory states the flaw is present in every version prior to 2.4.2, including the 2.4.2 release candidates.
• The instance was reachable from the internet while it ran an affected version. The vendor says it has not established when attackers first began exploiting the flaw.
• You have not rebuilt the server since. The vendor's recovery guidance applies even if you updated from an affected version after its November 1 warning and noticed no theft.

Hosted instances are in scope too: on November 1 the vendor asked hosting providers, including LunaNode, to take BTCPay Server instances offline as a precaution. Contact your provider for help moving to a fresh virtual machine.

Funds whose spending keys are held off the server, including hardware wallets, were unaffected by these thefts. Accepting payments into such wallets remains the vendor's recommended practice.

Affected versions miss every security fix that followed: releases 2.4.3 to 2.4.7 shipped security and hardening changes through October 29, 2026. Version 2.4.7 alone fixes 85 security findings reported through Anthropic's OSS Scanner.

Despite 7,888 GitHub stars and 4,131,130 pulls of the official Docker image, no CVE or GitHub security advisory exists for this flaw, so version scanners cannot flag the affected range.

Check what you run:

# Vendor's check: log in and read the version shown at the bottom of the page.

# Docker deployments: list the running container and its image tag
docker ps --format 'table {{.Names}}\t{{.Image}}' | grep -i btcpay
# If the tag reads "latest" or gives no version, the page footer is authoritative.

How do I fix it?

1. If you run 2.4.1 or earlier, follow the vendor's recovery steps instead of an in-place update:
2. Create a new wallet and sweep any remaining hot-wallet funds into it. Use a trusted device and a new seed; reusing the old seed on a new server leaves those funds at risk.
3. Take the old server offline, and preserve relevant logs and transaction records for the investigation before replacing it.
4. Provision a fresh virtual machine, install the latest supported release from trusted sources and connect the new wallet. Do not restore the entire old server onto the new machine.
5. From a trusted device, revoke and replace every credential the old server could reach. Do not enter new credentials on the old machine. The vendor names:
   • hosting and SSH credentials
   • application and API credentials
   • Lightning credentials
6. If your server already ran 2.4.2 or later on November 1, the vendor has seen no impact from these attacks on those servers. Update to the current release anyway, because 2.4.7 fixes 85 further security findings.
7. For a standard installation, use the vendor's update path (Server Settings, then Maintenance, then Update) and confirm the page footer shows the new version.
8. Integrators should also update NBXplorer to 2.6.10, as the 2.4.2 release notes recommend.

No configuration workaround exists for the flaw itself. In August, the vendor's interim advice for LND users who could not update was to take the server offline. An affected LND deployment should never stay accessible from the internet.

What is the root cause?

BTCPay Server closed two exposures on one day: public controller helper methods were routable as HTTP endpoints, and the reference Docker deployment proxied LND's APIs through the public domain. The vendor states it is not publishing the technical details yet, so operators have time to update.

The server-side fix is commit 6689cad419, "Disabled unwanted routes", pushed on August 7, 2026 by maintainer Nicolas Dorier with no pull request and no changelog entry. It adds the [NonAction] attribute to five public helper methods on controllers, including this one:

// BTCPayServer/Controllers/UILNURLController.cs, before 2.4.2
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

// after 2.4.2
[NonAction]
public async Task<IActionResult> GetLNURLRequest(
    string cryptoCode,
    Data.StoreData store,
    ...)

ASP.NET Core maps every public method on a controller class to a routable HTTP endpoint unless the method carries [NonAction]. The five helpers sit on the LNURL, LNURL-authentication, stores, email-rule and subscription controllers. Each is an internal building block that was never meant to receive a request.

The same day, the docker repository commit "Do not expose LND anymore" removed the two nginx locations that proxied the public domain straight to the Lightning node:

# Production/nginx.tmpl in btcpayserver-docker, removed on 2026-08-07
location ~* ^/(lnrpc|routerrpc|verrpc|walletrpc)\. {
    grpc_read_timeout 6000s;
    grpc_send_timeout 6000s;
    grpc_pass grpcs://lnd_bitcoin:10009;
}
location /lnd-rest/btc/ {
    rewrite ^/lnd-rest/btc/(.*) /$1 break;
    proxy_pass http://lnd_bitcoin:8080/;
}

A third commit the same day names the flaw class. Reverting a related removal, maintainer Andrew Camilleri wrote that CLN, another Lightning implementation, "is not affected by the LNURL issue". BTCPay reaches CLN over a Unix socket with runes, so "there is no macaroon for that code path to read", in his words. His message states that the LNURL code path reads the LND macaroon.

The August advisory describes the outcome: an unauthenticated remote attacker could obtain .macaroon credential files for LND.

How is it exploited?

The vendor's two posts describe the attack path; no public proof of concept exists, and the vendor has not published the requests the attackers sent:

1. The attacker reaches an affected server over the internet. The August advisory states that obtaining the .macaroon credential files required no authentication.
2. In the August attacks, the attacker obtained the .macaroon files, which carry authenticated access to an LND node. The vendor reviewed attacks that targeted only files with the .macaroon extension, and states those credentials could be used to take control of the node and move funds.
3. In the November attacks, the attacker used "a different method to exploit the vulnerability fixed in 2.4.2", in the vendor's words. The thefts took Bitcoin and Litecoin from the servers' on-chain hot wallets, and the vendor has not described the method.
4. No further access was needed to spend the funds, because a hot wallet stores the keys needed to spend them on the server itself. Wallets whose spending keys are held off the server were unaffected.

How does the attack flow?

An unauthenticated request reaches routes the vendor never meant to expose, and the attacker takes LND macaroon credentials or, in November, the on-chain hot wallet funds.

What can an attacker do?

The August attacks took control of an LND node and moved its funds, including the on-chain wallet that belongs to the node itself. The November attacks stole Bitcoin and Litecoin from the servers' on-chain hot wallets, which the vendor had assessed as unaffected when it reviewed the August attacks.

Once inside, the attacker is treated as owning the machine. The vendor tells anyone with stolen funds or signs of unauthorized access to consider the entire server and all its secrets compromised. The same recovery steps apply.

Two conditions bound the impact. The server must run 2.4.1 or earlier. Only funds the server itself could spend were at risk, so hardware wallets and other keys kept elsewhere stayed out of reach.

Why does the fix work?

The 2.4.2 release closes both exposures. The [NonAction] attributes remove the five helper methods from routing, so they can no longer receive requests. The nginx change takes LND's gRPC and REST interfaces off the public domain.

The documented cost is that external wallets such as Zeus lose access to LND through the BTCPay domain. The vendor plans to restore that path when it is safe.

Two same-day changes invalidate anything already stolen. The docker repository bumps LND to 0.21.1, and the LND_MACAROON_ROTATION_ID setting added on August 7 regenerates the macaroons. Macaroon files taken before the update stop working.

The fix is complete for the two exposures the commits close, but it cannot remove access an attacker already gained. That is why the vendor tells operators of affected versions to move to a fresh server rather than update in place.

The 2.4.2 release also fixes a TOTP two-factor authentication bypass available through Greenfield Basic authentication. It disables Basic authentication by default five minutes after account creation.

How do I check if I was compromised?

Check the version first: log in and read the footer. Then check the blockchain and your Lightning node:

• The vendor published two destination addresses identified in the incident reports. Look for outgoing transfers to the Bitcoin address bc1p0f7wmcnesrapznymf9ljdn04pudgmh96sqtrm9vmgqxdh666fh8qvn63r7 or the Litecoin address ltc1qp49tmfdueyaqrmgrx0uyx4uegyygt8yt02whee.
• Treat a hit as one lead among others. The vendor warns that some activity at these addresses appears to predate the thefts described in its reports, so their balances and histories are not a confirmed loss total.
• If you use or used LND, run the four checks from the vendor's August advisory:
• payments you did not make
• unexpected channel closures or unfamiliar peers
• on-chain and channel balances compared with your own records
• any activity you do not recognize
• An unchanged wallet balance does not rule out an earlier attack. If the server ran 2.4.1 or earlier and was reachable, treat the machine and all its secrets as compromised. Preserve the logs, then follow the steps in "How do I fix it?".

Timeline

• 2026-07-23: BTCPay Server 2.4.1 is released, the last release that carries the flaw.
• 2026-08-06 to 2026-08-07: the maintainers commit the composite fix across the server and docker repositories: "Disabled unwanted routes", "Do not expose LND anymore" and the macaroon rotation.
• 2026-08-07: BTCPay Server 2.4.2 ships. The advisory states that attackers had already exploited the flaw and that funds were stolen.
• 2026-08-24: 2.4.3 ships as a security release for servers shared with many users.
• 2026-09-07: 2.4.4 ships checkout and store hardening changes.
• 2026-10-06: 2.4.5 blocks private-network destinations for outbound requests by default.
• 2026-10-26: 2.4.6 hardens API permissions, untrusted input, generated links and browser actions.
• 2026-10-29: 2.4.7 fixes 85 security findings reported through Anthropic's OSS Scanner.
• 2026-11-01: a wallet drain described in the incident reports occurs at 13:46 UTC. The first theft report arrives by email at 20:56 UTC, and the vendor warns the community at 22:25 UTC.
• 2026-11-02: the vendor names 2.4.1 and earlier as the affected versions and publishes the recovery guidance.

FAQ

I do not use LND. Am I still at risk?

The August attacks the vendor reviewed targeted only LND macaroon files, and users of other Lightning implementations were not exposed to that credential risk. The November thefts took Bitcoin and Litecoin from on-chain hot wallets on servers running 2.4.1 or earlier. The recovery guidance now applies to every affected deployment, not only LND users.

I updated to 2.4.2 or later after the November 1 warning. Am I safe?

The vendor has seen no impact on servers that already ran 2.4.2 or later when the warning was issued. If you updated from 2.4.1 or earlier after that warning, the vendor still tells you to move to a fresh server with a new wallet. Updating cannot remove access an attacker may already have gained.

Is there a CVE I can scan for?

No. As of November 3, 2026, no CVE has been assigned and the GitHub repository carries no security advisory, so dependency scanners cannot flag the affected range. The version shown at the bottom of the page is the only version check, and the recovery steps in "How do I fix it?" are the remediation.

Are my hardware-wallet funds safe?

Yes. Funds in wallets whose spending keys are held off the server, including hardware wallets, were unaffected by these thefts. The vendor still recommends rebuilding an older server even if you keep your wallet keys elsewhere, because the attacker may hold other access to the machine.

What changed in the releases after 2.4.2?

They are security and hardening releases. Version 2.4.5 blocks private-network destinations for Lightning connections, LNURL requests, invoice notification URLs and webhooks by default. Version 2.4.7 fixes 85 security findings reported through Anthropic's OSS Scanner: one critical, 13 high, 52 medium and 19 low.

Find exposed payment servers with Ostorlab

Ostorlab's attack surface discovery inventories your internet-facing hosts and the services they expose. Use it to list which servers run a self-hosted payment processor, and check those versions first.

References

• BTCPay Server blog, "Security Incident Affecting BTCPay Server 2.4.1 and Earlier", November 2, 2026, the theft reports, recovery steps, timeline and destination addresses: https://blog.btcpayserver.org/btcpay-server-security-incident-2-4-1-and-earlier/ (checked November 3, 2026)
• BTCPay Server blog, "Security Advisory: Update BTCPay Server to 2.4.2 Immediately", August 7, 2026, the unauthenticated .macaroon theft, the LND scope, the credits and the interim advice: https://blog.btcpayserver.org/security-advisory-btcpay-server-2-4-2/ (checked November 3, 2026)
• btcpayserver commit 6689cad41979c73f769fd42e38268fed1fa800fa, "Disabled unwanted routes", Nicolas Dorier, August 7, 2026, the five [NonAction] additions: https://github.com/btcpayserver/btcpayserver/commit/6689cad41979c73f769fd42e38268fed1fa800fa (checked November 3, 2026)
• btcpayserver-docker commit 21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2, "Do not expose LND anymore", Nicolas Dorier, August 7, 2026, the removed nginx locations: https://github.com/btcpayserver/btcpayserver-docker/commit/21ea2e122ae5bc453ad1c0a4d6d6b6dd094dcca2 (checked November 3, 2026)
• btcpayserver-docker commit c48919f9ae51c714078076e7912dd153ba0bb01f, "Revert 'Do not expose CLN REST anymore'", Andrew Camilleri, August 7, 2026, the "LNURL issue" class description and the macaroon code path: https://github.com/btcpayserver/btcpayserver-docker/commit/c48919f9ae51c714078076e7912dd153ba0bb01f (checked November 3, 2026)
• btcpayserver-docker commit 4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0, "Triggering macaroon regeneration", rockstardev, August 7, 2026, the LND_MACAROON_ROTATION_ID setting: https://github.com/btcpayserver/btcpayserver-docker/commit/4caadeb0c3a31f88ca1a4ee46fd63d8b9db093c0 (checked November 3, 2026)
• BTCPay Server v2.4.2 release notes, August 7, 2026, the exploitation statement, the credits, the TOTP bypass fix and the NBXplorer 2.6.10 recommendation: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.2 (checked November 3, 2026)
• BTCPay Server v2.4.7 release notes, October 29, 2026, the 85 security findings by severity from Anthropic's OSS Scanner: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.7 (checked November 3, 2026)
• BTCPay Server v2.4.1 release, July 23, 2026: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.1 (checked November 3, 2026)
• BTCPay Server v2.4.5 release notes, October 6, 2026, the default block on private-network destinations: https://github.com/btcpayserver/btcpayserver/releases/tag/v2.4.5 (checked November 3, 2026)
• btcpayserver/btcpayserver repository, 7,888 stars, and its Docker Hub image, 4,131,130 pulls, the reach figures: https://github.com/btcpayserver/btcpayserver and https://hub.docker.com/r/btcpayserver/btcpayserver (checked November 3, 2026)
• The Hacker News, "Hackers Exploit BTCPay Server Flaw to Steal Bitcoin and Litecoin From Hot Wallets", November 3, 2026, the Zeus access note and the hosting-provider shutdowns: https://thehackernews.com/2026/11/hackers-exploit-btcpay-server-flaw-to.html (checked November 3, 2026)
• CISA Known Exploited Vulnerabilities catalog JSON feed, checked for BTCPay Server entries on November 3, 2026 (none): https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (checked November 3, 2026)