Lightning wallet security: five warnings since August and how to protect your node

A Lightning wallet is only as secure as the server its keys sit on. If you hold bitcoin on Lightning only in a widely used mobile app, the security warnings of the past three months did not affect you directly. If, on the other hand, you run your own Lightning node, a BTCPay Server, Alby Hub or LNbits, you have received five warnings since early August, and in at least two cases money was actually drained. The lesson from all five is the same: an update closes the hole, but only new credentials and a small balance on the server make Lightning safe again.

Lightning is to bitcoin what a debit card is to a savings account: a fast payment route for small amounts. That is precisely why keys sit on machines that are permanently connected to the internet. This article brings the individual cases together, explains the common pattern and shows how much balance should actually be kept on a Lightning node. How the network works technically is explained in our introductory guide to the Bitcoin Lightning Network.

Lightning security flaws since August: five warnings in three months

The series begins on August 7, 2026. BTCPay Server, widely used free software that lets merchants accept bitcoin payments themselves, released version 2.4.2 as an emergency update. According to the project's security advisory, an attacker could grab the permission files of a connected LND node without logging in. The project confirms that attackers exploited the flaw and stole funds.

On August 28, Core Lightning, one of the three major implementations of the Lightning protocol, followed with version 26.06.7. The update closed several confirmed vulnerabilities. Anyone unable to update immediately was advised to restart the node with the --offline switch. No losses had been reported at that point. There was a sequel for Docker users: until September 1, four images shipped a build that identified itself as 26.06.7 but did not contain the fixes. The details are in our article on the Core Lightning vulnerability.

On September 8, BTCPay Server reported another risk. Automated programs were specifically probing servers on which operators had manually reopened the access to the LND interface that had been closed in August. A day later, Alby Hub, software for running your own Lightning node at home or on a rented server, issued a warning: versions v1.7.0 to v1.18.5 were vulnerable if the admin interface was reachable from the open internet. One user was confirmed as affected.

The most recent case concerns LNbits. On November 8, the project discovered a flaw through which attackers drained funds from self-hosted instances. Version 1.7.0 was released on November 10, together with a call not to start any server with an older version. What exactly happened there is described in our article on the LNbits security flaw.

The five cases at a glance

• August 7, BTCPay Server 2.4.2: permission files of LND nodes exposed, thefts confirmed.
• August 28, Core Lightning 26.06.7: several vulnerabilities, no reported losses, faulty Docker images until September 1.
• September 8, BTCPay Server 2.4.4: bots searching for reopened LND access points, no successful takeover reported.
• September 9, Alby Hub: publicly reachable admin interface vulnerable, one confirmed case.
• November 8 to 10, LNbits 1.7.0: thefts from Lightning wallets, total damage unknown.

Lightning wallet and hot wallet: where the keys are kept

A Lightning wallet is a wallet that sends and receives bitcoin over the Lightning Network instead of writing every payment to the blockchain individually. To do this, a node opens payment channels to other nodes. A payment channel is an amount that two parties lock together in a bitcoin transaction and then use to pay back and forth as often as they like.

For the node to forward payments within seconds, it must be able to sign at any time. Its keys are therefore stored on a machine connected to the internet. That is exactly what a hot wallet is: a wallet whose keys are available online. The counterpart is the cold wallet, whose keys sit on a device without a permanent connection, such as a hardware wallet.

This leads to the most important difference from long-term storage. Nobody can move a bitcoin reserve held on a hardware wallet over the internet as long as the seed is stored safely. A Lightning node, by contrast, can move everything in its channels and its on-chain wallet as soon as an attacker has the right credentials. LNbits states this explicitly in its advisory: the software is a hot wallet, and with AI-assisted attacks the risk is higher than ever.

Custodial Lightning wallet or your own node: who the flaws hit

Lightning comes in two designs. With a custodial Lightning wallet, a provider runs the node and you only see a balance in the app. With a self-custodial wallet, you run the node yourself or let an app run a small node on your phone. All five warnings concerned software that operators install themselves: on a home server, a ready-made package such as Umbrel or Start9, or a rented machine.

In between sits a third group that is easily overlooked. If you were given a Bolt Card at a bitcoin meetup, paid through a Lightning till in a café or received a wallet as a gift via a link, you are often using an account on someone else's LNbits server. These users cannot install an update and depend on the operator having responded.

This gives a simple breakdown for the three groups:

• App wallet or exchange only: not directly affected. Updating the app never hurts, though.
• Account on someone else's LNbits server: ask the operator whether version 1.7.0 is running and whether the keys have been reissued. Until then, small amounts only.
• Your own node, BTCPay Server, Alby Hub or LNbits: check the version, close access points, rotate credentials.

Open admin access: the common pattern behind BTCPay, Alby Hub and LNbits

The five cases have different technical causes, but the three warnings from BTCPay and Alby Hub follow the same pattern. An interface intended only for the operator was reachable from the internet or could be addressed without logging in. At BTCPay, it was the LND node's permission files in August, and in September an endpoint for changing passwords that some operators had reopened to the outside themselves. At Alby Hub, it was the admin interface. At LNbits, the attack route has not yet been disclosed; a separate report is to follow. What is known is that, according to Cointelegraph, attackers created new accounts and used them to drain around 2.3 million satoshis from a single instance, which is 0.023 bitcoin.

A satoshi is one hundred-millionth of a bitcoin. The known individual loss is therefore small. The loss that would have been possible is not: anyone holding a node's credentials can move the entire outbound balance within the limits of the channels, not just that of a single sub-account.

In practice, this means the most effective protection costs nothing. An admin interface that is only reachable on the home network or through an encrypted tunnel such as Tor or WireGuard was not vulnerable in any of the Alby Hub cases or the BTCPay case in September. What this looks like for Alby Hub is shown in our article on the Alby Hub security flaw, and for BTCPay Server in the guide to securing Lightning access.

Macaroons, API keys and wallet keys: why an update alone is not enough

An update closes the route an attacker came in through. Whatever they took beforehand remains valid. BTCPay Server and LNbits both stress this point. In its advisory on version 1.7.0, LNbits writes that credentials leaked before the update can still give an attacker access afterwards.

In LND, these credentials are called macaroons. A macaroon is a key file with tiered permissions. The admin macaroon is the master key: it can trigger payments and close channels. LNbits additionally works with its own wallet keys for each sub-account and with the credentials for the funding source, meaning the node or payment service through which the instance moves its balance.

The clean-up after an incident therefore always follows the same order. First comes the update, then all keys are revoked and regenerated, and only then does the server accept payments again. LNbits names six extensions whose connections operators should delete and recreate: NWC Provider, LNDHub, Bolt Cards, TPOS, Bleskomat and FOSSA. NWC stands for Nostr Wallet Connect, a method that allows apps to trigger payments from a wallet remotely. A forgotten NWC connection can remain an open door even though the server has long been up to date.

If a break-in is suspected, both projects recommend a fresh system. LNbits advises installing the software on a new server and backing up the old one's log files first. BTCPay Server advises checking outgoing payments, unexpected channel closures and unknown peers, and comparing balances with your own records.

AI-assisted bug hunting: Lightning software is under more pressure

One factor links the cases beyond the technology. At the end of August, the Core Lightning team reported that it had spent weeks processing an unusually high number of vulnerability reports generated with AI tools, several of which turned out to be genuine. In November, LNbits explicitly cited the rise in AI-assisted attacks as the reason for its recommendation to keep only a little money online.

For operators, this changes the pace. Bugs that used to go unnoticed for months now surface faster, for defenders and attackers alike. Free Lightning software is often maintained by small teams. At LNbits, two days passed between discovery and fix, and the attacks were already under way during that time. Anyone running their own node therefore needs a way to catch such notices: subscribe to the announcement channels of the software in use, check automatic updates and do not leave the server running unattended for months.

For most investors, this is an argument against running your own server. If you only use Lightning for the occasional payment, a well-maintained app usually serves you better. Which programs are suitable is shown in our software wallet comparison.

Hot wallet and cold wallet: how much bitcoin belongs on a Lightning node

Perhaps the most important rule comes at the end of the LNbits advisory and applies to every Lightning wallet: only the money needed for day-to-day operation belongs online. Check balances and outgoing payments regularly and move surpluses to an on-chain wallet whose keys are kept offline.

How much operating money is appropriate depends on the purpose. For a private Lightning wallet, what you plan to spend over the next few weeks is enough, comparable to the cash in your wallet. A merchant with a Lightning till needs enough outbound capacity for refunds and change, and the rest moves to the cold wallet in the evening or weekly. A node that forwards payments for others needs more channel capacity and therefore also more attention.

The cold wallet itself should be a hardware wallet whose seed is stored separately from the device. Suitable devices are compared in our hardware wallet comparison. Separation is what matters: the seed of your reserve has no business on the Lightning server, not even as a file in a backup folder.

Lightning in everyday life: Bolt Card, shop till and app wallet without your own server

If you pay with Lightning without running a server, you usually use one of three forms. An app wallet on your phone runs the node itself or connects to a service. A Bolt Card is an NFC card that lets you pay at a till via Lightning; the balance sits on the server that issued the card. A Lightning till in a shop runs on the merchant's side.

With the Bolt Card and with wallets gifted via a link, the risk lies with the operator. If they issued new keys after the LNbits incident, old cards and links are worthless. In the worst case, an attacker knows them too. A new card or a new link from the operator therefore always replaces the old version. If you hear nothing back, such an account should hold no more than the price of a coffee.

If, by contrast, you buy bitcoin on an exchange and keep it there, Lightning flaws in self-hosted software do not affect you. In the EU, such a provider has needed a licence under the European MiCA regulation since the end of the transition period. Which exchanges have one is shown in our comparison of regulated crypto exchanges. Custody with a provider does not replace self-custody; the risk then lies with a supervised company.

Securing a Lightning node: five settings in order of priority

The five warnings yield a fixed order that applies to any self-hosted Lightning software:

1. Version: BTCPay Server 2.4.4 or later with LND 0.21.1 or later, Core Lightning 26.06.7 or later with a verified Docker image, Alby Hub v1.24.0 or later, LNbits 1.7.0 or later.
2. Reachability: admin interfaces and LND interfaces only on the home network or through a tunnel; remove any home-made port forwarding.
3. Credentials: after every incident, regenerate macaroons, API keys, wallet keys and passwords, and recreate app connections.
4. Balance: only operating money on the node, surpluses moved regularly to the cold wallet.
5. Monitoring: review outgoing payments, new accounts and channel closures once a week.

This list does not replace each project's own advisory; it only puts them in order. In a new incident, what the developers themselves write always comes first.

Using a Lightning wallet safely: only operating money belongs on the server

1. Bring your Lightning software up to date and then rotate all credentials. For the reserve kept off the server, you will find a suitable device in the hardware wallet comparison.
2. Ask yourself whether you need your own node at all. For occasional payments, a well-maintained app from the software wallet comparison is often enough.
3. Keep larger holdings with a supervised provider or offline. Exchanges with a MiCA licence are listed in the comparison of regulated crypto exchanges.

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