Lightning wallet security: five warnings since August - CryptoTicker.io

BTCPay Server, Core Lightning, Alby Hub and LNbits have reported security flaws since August 2026, and in at least two cases money was drained. This overview shows the common pattern and how to use a Lightning wallet safely. 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, however, you run your own Lightning node, a BTCPay Server, Alby Hub or LNbits, you have received five warnings since early August.

The lesson from all five incidents 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.

Security flaws since August

The series of security warnings began on August 7, 2026, when BTCPay Server 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 confirmed that attackers exploited the flaw and stole funds.

On August 28, Core Lightning followed with version 26.06.7, which 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.

On September 8, BTCPay Server reported another risk where automated programs were probing servers on which operators had manually reopened access to the LND interface. A day later, Alby Hub 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.

Hot wallet vulnerability

A Lightning wallet is a wallet that sends and receives bitcoin over the Lightning Network instead of writing every payment to the blockchain individually. 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.

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.

Who is affected

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. Account on someone else's LNbits server: ask the operator whether version 1.7.0 is running and whether the keys have been reissued. Your own node, BTCPay Server, Alby Hub or LNbits: check the version, close access points, rotate credentials.

Common pattern

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 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, but anyone holding a node's credentials can move the entire outbound balance within the limits of the channels.

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.

Beyond updates

An update closes the route an attacker came in through, but 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 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.

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. 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.