LNbits ships version 1.7.0 after attacks drained wallets and tells every operator to change their keys

Update, 11 November 2026, 05:55 UTC: LNbits released version 1.7.0 at 17:09 UTC on Tuesday 10 November, an “urgent security update” that its GitHub notes tell all users to install immediately. In its upgrade guidance the project says every version before 1.7.0 is affected, and asks operators to reset wallet keys and replace funding-source credentials, because updating alone may not remove access an attacker already has. A full report on the exploit is still to come, and no total loss has been published.

LNbits, the open-source software that turns a Lightning node into a set of separate wallets for tipping bots, shops and payment apps, told every operator on Sunday 8 November to stop their servers “IMMEDIATELY” after a wave of attacks. One operator says freshly created accounts on his instance withdrew 2,285,545 sats, about $1,690 at bitcoin’s 08:09 UTC price on Monday. Two days later, on 10 November, LNbits released version 1.7.0 with the promised security fixes and told operators to upgrade before running the software again, then to change every key it holds.

The LNbits attack is small in dollars. Its reach is harder to measure: LNbits runs on home-node platforms such as Umbrel, on self-hosted servers and on the project’s own hosted service, and while the team now says every version before 1.7.0 is affected, it has not yet explained how the attackers got in or said how much was taken in total.

Two LNbits warnings within 90 minutes on Sunday

The first alert came at about 12:33 UTC on 8 November. LNbits asked operators who use its Paywall extension, a plug-in that locks content behind a Lightning payment, to switch it off while the team looked into a possible vulnerability, according to Bitcoin.com’s account of the shutdown.

Some 80 minutes later the warning covered everyone. “All LNbits users should stop their LNbits servers IMMEDIATELY,” the project’s official account @lnbits wrote on X at around 13:56 UTC (8:56 a.m. in New York), adding that it had “a number of security patches to push”. CryptoNews also reported that the order went beyond Paywall users.

The full announcement, summarised by the outlet TechFlow at 15:43 UTC on 8 November, spoke of a wave of attacks and of several security fixes that had yet to be released. Stopping the servers was presented as a precaution until those patches were out. The team promised more updates as soon as possible and gave no technical detail.

New accounts, then withdrawals: what one LNbits operator lost

The only loss figure on the record comes from a single operator. Kevin Ravensberg, a Dutch operator whose LNbits instance backs the Telegram tipping bot BitTipBot, said that newly created accounts withdrew 2,285,545 sats (0.02285545 BTC) between 09:22 and 14:00 UTC on 8 November, when he stopped the server, Bitcoin.com reported. CryptoNews put the figure at about 2.29 million sats.

Those times matter. By his account the withdrawals began more than three hours before LNbits posted its first warning, and they ran until just after the general shutdown call. Ravensberg pledged to reimburse BitTipBot users. Their balances come back only when he restarts the instance on a fixed version, and no restart of BitTipBot on 1.7.0 had been announced by the morning of 11 November.

The blockchain security firm SlowMist added the case to its public hack tracker on the same day. Its entry lists LNbits, a software vulnerability as the cause and a loss of $1,700, and describes the method in one line: attackers created new accounts and withdrew funds without authorisation. That matches the operator’s account. It also seems to rest on that one case, since no other operator has published a loss.

A pattern of “create an account, then pay out” points to a weakness in how LNbits checks who may spend from which wallet, but neither the project nor SlowMist has said so. Whether other instances lost money, and how much, is not known.

What LNbits is, and why so many small services sit on it

A Lightning node holds one smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool of bitcoin in its channels. LNbits sits on top of that node, whether it runs LND, Core Lightning or another backend, and splits the pool into many accounts, each with its own wallet and API keys. That is what lets a single operator run a tipping bot for thousands of chat users, a point-of-sale terminal for a shop or a set of LNURL withdraw links without giving anyone access to the node itself.

Extensions add the rest: paywalls, shops, withdraw links, payment terminals. Since version 1.6.0, released on 2 September 2026, extensions can run in a WebAssembly sandbox, according to the project’s release notes. The same release fixed two weaknesses reported by the security group V12, an authentication cache bypass and a flaw in the PayPal integration, Bitcoin.com noted. Nothing links those bugs to Sunday’s attacks.

For users, the key point is custody. Funds in an LNbits wallet are held by whoever runs the instance, so a tipping-bot balance is a claim on that operator’s node. Our guide to crypto wallet types and who holds the keys explains the difference between a self-custodial wallet and a balance kept on someone else’s service. Our explainer on layer 1 and layer 2 networks shows where Lightning sits next to the bitcoin blockchain.

The shutdown call concerns LNbits servers. No report so far says the underlying Lightning nodes or their channels were compromised. LNbits is also a different project from LNbank, a BTCPay Server plugin that had its own incident earlier.

The hosted my.lnbits.com was shut down too, with a restart promised within 24 hours

LNbits also runs a paid hosting service, my.lnbits.com, for people who do not want to manage a server. All of its instances were shut down as a precaution, with services expected to resume within 24 hours, TechFlow reported at 19:49 UTC on Sunday; CryptoNews and The Defiant also reported the hosted instances switched off. Counted from that report, the restart would fall on Monday evening, but LNbits had not announced it by 08:16 UTC on Monday. It has not said whether any balances on the hosted service were touched, and its 1.7.0 notice does not mention the hosted service at all.

Before the patch: 24 to 48 hours promised, version 1.6.2 still online

Ben Arc, a core contributor to LNbits, said the patches “should be merged and available within 24-48hrs”, CryptoNews reported. TechFlow and The Defiant gave the same window, and Bitcoin.com wrote of about one to two days. Counted from Sunday, that window closed on Tuesday 10 November, the day version 1.7.0 came out.

At 08:16 UTC on Monday the project’s GitHub page still showed version 1.6.2 as the latest release. It dates from 18 September and was a hotfix for PostgreSQL backups. Tags for two release candidates, v1.7.0-rc1 and v1.7.0-rc2, existed without a release page. Umbrel’s app store still listed 1.6.2 at that point; its app repository moved to 1.7.0 at 18:05 UTC on Tuesday.

One pull request, #4310, opened by the maintainer account arcbtc at 21:38 UTC on Sunday, is titled “fix: centralize SSRF protection and block self-targeted requests”. It had no description and no link to the attacks. Another maintainer, motorina0, merged it into the project’s development branch at 12:26 UTC on Monday, and its change is part of version 1.7.0, although the release notes do not list it. Nothing shows it was the fix for the attacks. Before that merge, the last changes in the main branch dated from 6 November and were routine bug fixes, and the two pull requests opened early on Monday were titled as ordinary fixes too.

The project’s security advisories page showed no entry for this incident at 08:16 UTC on Monday, and none had been added on the morning of 11 November, after the release. It lists only two older cases, CVE-2024-34694 and CVE-2025-32013, the second an SSRF flaw fixed from version 0.12.12.

LNbits 1.7.0: every earlier version affected, keys to change

LNbits published version 1.7.0 on GitHub at 17:09 UTC on Tuesday 10 November, under the title “URGENT SECURITY UPDATE”. The release notes ask all users to update immediately and describe hardening of authentication, extension management and payment handling, along with updated dependencies such as urllib3, Tornado, Werkzeug, aiohttp and certifi. They name no CVE and do not say which bug the attackers used.

The release also carries features built over the past weeks, among them two-factor authentication, on-chain wallets and BOLT12 offer payments. One addition matters for the clean-up: a button that lets the Super Admin reset every wallet key on an instance at once.

In its upgrade guidance on news.lnbits.com, dated 10 November, the project says all versions before 1.7.0 are affected and that funds running on them “are at risk of being stolen”. It warns that credentials exposed before the upgrade may still give an attacker access afterwards. A separate report with the full details of the exploit is promised, without a date.

Ben Arc, the core contributor who created LNbits, wrote on X of “a very challenging few days, working relentlessly to get the v1.7 release out after our users and we suffered losses”, Cointelegraph reported on 11 November. The outlet also recalled his estimate, given in May, that about 200,000 people run the software themselves.

The loss count has not moved. LNbits had not published a total across the affected instances when it released 1.7.0, Bitcoin Magazine noted on 10 November. Ben Arc’s post puts no figure on the team’s own losses either, so the 2,285,545 sats reported by BitTipBot’s operator remain the only public number, and LNbits has not said how many instances were hit.

What LNbits has still not said

One of the open questions is settled: the vulnerable versions are all those before 1.7.0. Three others have no public answer yet. LNbits has not described the attack route, beyond what the operator and SlowMist observed, and leaves that to its full report. No one has given a total loss across all instances: the 2.29 million sats belong to one server. And no CVE number or GitHub security advisory has been published for the incident.

The figures that are public fit in a short table.

What LNbits now tells operators and users to do

The instruction has changed. Operators must upgrade to 1.7.0 before running LNbits at all, then take recovery steps, because keys stolen before the upgrade can still work after it. The steps listed in the 10 November guidance are these.

• If a compromise is suspected, install 1.7.0 on a new server rather than updating the old one, and keep the old server’s logs and records first.
• Log in as Super Admin, open Settings, then Users, and choose Reset Wallet Keys. The old keys stop working, so users must update every app connected to their wallets.
• Revoke and replace the credentials of the funding source, such as API keys or LND macaroons, then enter the new ones in the LNbits settings.
• Treat any other secret stored in the LNbits settings as compromised and replace it.
• Delete and recreate the connections of the extensions that hold them: NWC Provider, LNDHub, Bolt Cards, TPOS, Bleskomat and FOSSA.

The project adds a reminder that LNbits is a hot wallet. It asks operators to keep online only what daily operations need, to check balances and outgoing payments often, and to send the rest to an on-chain wallet whose spending keys stay offline.

People who only use a service built on LNbits, such as a tipping bot or a shop’s Lightning till, depend on their operator. Their balances sit on the operator’s node, and after a key reset any app linked to an LNbits wallet, an LNDHub account or a Bolt Card for example, needs the new keys. BitTipBot’s case shows the stakes: its operator has said he will cover what was taken.

Another Lightning-side alarm, a week after BTCPay Server’s

The LNbits call comes one week after BTCPay Server, the merchant payment software, asked all its operators on 1 November to shut down when hot wallets were swept, as we reported in our piece on the BTCPay Server thefts. The next day we reported a preprint’s estimate that 71% of exposed LND nodes still ran old software. In October, Eclair, another Lightning node implementation, shipped a patch that stops web pages from sending commands to its nodes. Bitcoin.com also cited newhedge.io data showing public Lightning capacity down more than 1,100 BTC since late July.

These cases have different causes and nothing ties them together. What they share is the layer they hit: the self-hosted software that small merchants and hobbyists run around bitcoin’s payment network, often on home servers, without a security team.

The incident is not moving the market. Bitcoin traded near $73,730 at 08:09 UTC on Monday, down 2.75% over 24 hours, while total crypto market capitalisation was down 6.68%, a slide that began before the LNbits news. The next thing to watch is the full technical report LNbits has promised, which should say how the attackers got in and whether other instances lost funds.