Securing BTCPay Server: Why Updating to 2.4.4 Alone Does Not Protect Your Lightning Node

Straight to the point, because it is the question that brought you here: the update to BTCPay Server 2.4.4 closes the public default route to your Lightning node. It does not remove a route you built yourself. Anyone who at some point exposed their server's LND interface through their own reverse proxy therefore has two jobs: update, and take that access away again. The project behind BTCPay Server says exactly that in its announcement of September 8, 2026.

The trigger is not a fresh theft. The project is seeing automated programs probing servers on which this access has been reopened by hand. No successful takeover by this route has been reported so far, and the project draws no link to the people behind the August incident. That is the good news in this: there is a window in which the problem can be resolved without damage.

For you as a holder or a merchant, more hangs on this than a server detail. A self-hosted payment server is the point where incoming Bitcoin payments, the keys to your Lightning node and your working balance all come together. Lose access there and you lose real money, not configuration. Which puts a second question on the same desk: how much balance really needs to sit permanently on a node that hangs on the internet, and what belongs in cold storage? If you have not drawn that line yet, our hardware wallet comparison is a better starting point than any further proxy rule.

What is happening right now: bots are calling an unprotected LND endpoint

The project describes the pattern openly. Automated programs repeatedly call one particular path of the LND programming interface: the endpoint for changing the wallet password at /lnd-rest/btc/v1/changepassword. The servers affected are explicitly those on which this access was manually switched back on after BTCPay Server disabled it by default in August.

The point that makes this delicate: the endpoint requires no authentication as long as the LND wallet is still locked. That is not a bug in the narrow sense but the design of the interface. A locked wallet cannot authenticate anyone yet, so the route to unlocking and to changing the password has to be reachable without credentials. As long as that route is reachable only inside the server, it is harmless. Only publishing it to the open internet turns it into a way in.

Macaroon, LND and reverse proxy: the three terms the rest depends on

LND is one of the common implementations of the Lightning Network, the payment layer that settles Bitcoin transfers in seconds and for fractions of a cent. If your BTCPay Server accepts Lightning payments, LND is almost always what sits underneath.

A macaroon is the credential with which LND permits commands. Think of it as a key file with graded rights. The admin macaroon is the master key: whoever holds it controls the node's wallet and its payment channels.

A reverse proxy is the server process that takes incoming requests from the internet and passes them to the right internal service. BTCPay Server ships with one of its own. Many operators have set up a second one alongside or in front of it, for instance to let a mobile wallet talk to their node while they are out. That self-built forwarding rule is precisely what this is about.

Why the window after an LND restart exists at all

The sequence is unspectacular, which is what makes it effective. After every restart of LND the wallet is locked at first. BTCPay Server has an internal unlock that supplies the password automatically. Between the service starting and the moment that unlock takes effect there is a short span.

If the interface is reachable from the open internet during that span, an attacker can be faster. The project describes the consequence soberly: whoever submits the known password at that moment can set a new one and have LND issue them an admin macaroon that controls the node. From then on the master key belongs to someone else.

One detail from the past made this worse: older BTCPay installations created their LND wallets with a shared default password. So there was nothing to guess. Anyone who knew the default only had to knock at the right moment.

The August theft and the September probing are two separate events

The distinction matters, because German-language coverage stopped in August and the two events blur into one easily.

The older event, August 7, 2026. The project published a security advisory for version 2.4.2. All earlier releases contained a hole through which an unauthenticated remote attacker could retrieve LND's macaroon files. The project confirms explicitly that the hole was exploited, that users were affected and that funds were drained. BTCPay Server's own on-chain wallets were not covered by this, the hot ones included; balances in LND's on-chain wallet, by contrast, belong to the affected node. The project and supporters later offered a reward of ten percent of any recovered Bitcoin, capped at three BTC, around $190,000 at the time.

The new event, September 8, 2026. Here there is no reported damage so far. It concerns bots looking for a way in, and a precaution taken by the project. Conflating the two claims a loss that no source supports.

What the update to BTCPay Server 2.4.4 actually closes

By its own account the project tackles the sequence described above on two fronts.

First: an end to the shared password. The new LND image no longer creates wallets with a shared default password. Every newly generated wallet gets its own random password. Existing wallets still sitting on the old default are migrated automatically at startup. That removes the part of the attack which relied on prior knowledge.

Second: blocking at the network edge. The Docker setup blocks the unauthenticated routes for creating and unlocking the wallet in the bundled reverse proxy itself. Via the public default path, the restart window is now shut.

2.4.4 brought further changes that may affect you in operation even though they have nothing to do with the attack. NFC payments in checkout are now off by default and have to be switched back on in the store settings. Invoices without an amount are blocked by default. Setting up Boltcards through a card reader attached to the computer is gone; instead BTCPay Server opens the corresponding app. Anyone using the WHMCS integration needs version 4.0.0 of the plugin because of a breaking change, plus a newly generated API key. Invited store users have to accept their invitation first. And the point-of-sale module no longer allows a separate notification address per request; the one stored in the module applies.

The standard Docker setup has made a bigger jump at the same time: Bitcoin Core moves from 29.2 to 31.1, LND to 0.21.3-beta. Support for Bitcoin Knots was removed after Knots, according to the project, followed a chain that split off from the main chain. Anyone deliberately running Knots should read that before the update rather than after. On top of that comes a tighter binding to the host machine: instead of broad SSH access, the application container now only gets a key for a small list of permitted maintenance commands.

Why your own reverse proxy rule is untouched by the update

This is the core, and it is the same sentence the project already wrote in August: an update to BTCPay Server does not close access routes that you manage separately from it. A forwarding rule in your own reverse proxy, a forwarded port on your router, a Tor service you set up yourself — the update knows none of these and cannot take them back.

The project's instruction is accordingly unambiguous: do not expose the LND interface to the internet by hand through a reverse proxy of your own. If you have already done so, remove that access and update your server. Both of them, readable in that order, not as alternatives.

Anyone who was already exposed through a route of their own in August should additionally rotate their node's credentials. The update to 2.4.2 regenerated the macaroons of the standard installation automatically; that does not apply to self-managed paths. You know the same logic from the Core Lightning vulnerability at the end of August, which we took apart in this analysis of the Core Lightning hole: the dangerous assumption is never the hole itself, but the belief that a version bump handles everything that follows.

External Lightning access is back, but only with an explicit opt-in

For many operators the shutdown in August was painful, because it also removed the legitimate route: a mobile wallet such as Zeus operating your own node while you are out. The project has never disputed that and announced an orderly way back in September.

Where things stand today: a change to the routing was merged on September 11 and offers a supported option for remote access, while the interfaces of LND and Core Lightning stay off by default. That is the decisive difference from the old situation: the access exists, but you have to switch it on deliberately, and it then runs over the path the project maintains rather than over your own handiwork.

In practice that means: if you need remote access, use the switch provided and stop building a forwarding rule of your own. And take the opportunity to check which wallet on your phone should have access to your node at all. Which software wallets support which connection types is set out in the software wallet comparison linked below; not all of them come with the same permission levels, and remote access with a restricted macaroon is considerably more harmless than one with the master key.

The checklist for operators: what you work through today

In order, and regardless of whether you feel affected:

1. Establish your version. The running release is shown in the footer of the admin area. If it is anything below 2.4.4, that is your first move.
2. Update. On a Docker installation via Server Settings › Maintenance › Update. On an installation managed differently, by your usual route.
3. Look for forwarding rules of your own. Go through your proxy configuration and watch for any rule that reaches anything below /lnd-rest/ out to the internet. Think of forwarded ports on the router and of Tor services you set up yourself as well.
4. Remove any routes you find. Do not comment them out and leave them lying there; take them out and reload the service.
5. Rotate credentials if your node was reachable over a self-managed path. Generate new macaroons, invalidate the old ones, set up stored connections in mobile wallets again.
6. Set up remote access again if you need it, through the setting provided rather than through rules of your own.

If you lack the time to do points three and four properly, the advice from the August notice still applies in spirit: a node that cannot be reached cannot be probed either. Better a few hours without remote access than an open endpoint over the weekend.

How to tell whether your LND node has been compromised

The project published a checking routine for the August incident that holds here too. Look in your node for payments you did not initiate. Watch for channel closures you did not trigger and for counterparties unknown to you. Reconcile your on-chain balance and your channel balances against your own records. Anything you cannot explain is a reason to keep looking, not a reason to relax.

One note for perspective, so that no panic arises here: a takeover by the route observed in September has not been reported by anyone so far. The check is diligence, not damage assessment.

To be considered separately is a third incident that the project discloses in the same announcement: its self-hosted server for building plugins was compromised, discovered on September 2. According to the project, only plugin developers are affected, not their users. Published plugins were checked and had not been replaced by malicious versions, and all access tokens were rotated. Stored email addresses were probably readable; anyone registered there should expect phishing attempts over the coming weeks and treat unexpected messages accordingly.

What the incident means for German merchants accepting Bitcoin payments

In Germany, BTCPay Server is used above all by small merchants, trade businesses, clubs and online shops that want to accept Bitcoin without an intermediary. The appeal lies in the payment going straight into your own wallet. There is no service provider holding the funds in the meantime.

This design has a flip side that the current case demonstrates: where nobody sits in between, there is also nobody who is liable, who blocks or who refunds. With a custodial provider an attack would be their problem. On your own server it is yours. Responsibility for updates, for access routes and for the split between working balance and reserve rests entirely with you.

From that follows a plain operating rule that holds independently of any single vulnerability: only as much sits on the node as day-to-day payment traffic requires. Everything beyond that moves regularly into storage that does not hang on the internet. Automating that outflow and running it weekly rather than quarterly caps the damage of any future incident at a manageable sum.

Records and tax: what the tax office requires for Bitcoin payments

One point that tends to get lost in security topics but will meet you at the next audit at the latest: if your business accepts Bitcoin as payment, the inflow is business income. What counts is the value in euros at the time of the inflow, and that value needs documenting. The one-year holding period of section 23 of the German Income Tax Act, which can make private sales tax-free, does not apply to business assets. Gains and losses from a later sale stay in the business and run through section 15 of the same act.

For VAT the position has been settled for some time: the European Court of Justice ruled in case C-264/14 that exchanging conventional currency for Bitcoin and back is exempt from VAT; the German Federal Ministry of Finance implemented this for Germany in a circular dated February 27, 2018. Your actual supply of goods or services remains taxable regardless of that, measured in euros.

In practice that means: for every payment you need the time, the amount in Bitcoin, the euro rate applied and the source of that rate. BTCPay Server keeps these details in its invoice data and lets you export them. Use that before a server migration or an incident renders the database unusable. That records are subject to retention requirements, and that access has to remain possible throughout the retention period, follows from section 147 of the German Fiscal Code and applies to an SQL database just as it does to a ring binder.

When running your own node pays off, and when it does not

After two security notices in five weeks, the question of whether the effort is still proportionate is a fair one. An honest answer has to name both sides.

In favour of your own node: nobody holds your money, nobody can freeze your account and no fee per transaction flows to a service provider. For small amounts on the Lightning Network that is a noticeable difference, because a percentage cut on a two-euro purchase would be out of all proportion.

Against it stands the operating effort, and that is real. You need somebody who reads security notices, applies updates and documents access routes. If that person is missing from the business, a custodial payment provider is the more honest choice despite its fees. A badly maintained node of your own costs more than any commission, and it does so exactly once.

A middle way that works well in practice: your own node for day-to-day business with a limited balance, fixed outflows into cold storage, and a calendar entry that forces you once a month to read the project's publications. All of the past weeks' notices would have been seen in time that way.

Securing BTCPay Server: what you take away from this

1. Update to 2.4.4 and remove your own LND forwarding rules. The update alone is not enough if you have built a route to the outside yourself. In the same pass, cut the balance on the node down to operational needs; the rest belongs in storage without a network connection, of the kind our hardware wallet comparison sets side by side.
2. Set up remote access again if you need it. Use the setting provided rather than a proxy rule of your own, and issue a macaroon with restricted rights while you are at it. Which mobile wallet handles which connection type and which permission levels is shown by our software wallet comparison.
3. Secure your payment records before you start working on the server. Export the invoice data with time, amount and the euro rate applied. Anyone doing this continuously rather than once a year will find suitable tools in our overview of crypto tax software and portfolio trackers.

The two primary sources in full: the announcement of BTCPay Server 2.4.4 of September 8, 2026 and the security advisory for version 2.4.2 of August 7, 2026.

(As of September 16, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)