LNbits has told every operator to install version 1.7.0 before running the software again. In a 10 November 2026 security update, the project said a vulnerability discovered on 8 November affects all prior versions, and that “funds running on prior versions of LNbits are at risk of being stolen.” The same day’s GitHub release, titled an urgent security update and published at 17:09 UTC (17:09 Europe/London), is more blunt still: “ALL LNBITS USERS SHOULD UPDATE IMMEDIATELY.”
An upgrade is necessary, but it is not the whole job. LNbits says credentials exposed before the upgrade may still give an attacker access afterwards, and that updating alone cannot remove access an attacker may already have gained. Operators who suspect a compromise are told to prefer a fresh server, reset every wallet key, replace funding-source credentials and other secrets, and rebuild a list of connected apps. No CVE has been published, no loss figures have been given, and the project says a full exploit report will come later.
In brief
- LNbits 1.7.0 is an urgent security release. Every version before it is affected, and the project says funds on those versions are at risk of theft. Leave unpatched instances stopped until 1.7.0 is installed.
- Upgrade first, then treat recovery as a separate step: a fresh server if compromise is suspected, a reset of all wallet keys, new funding-source credentials, and recreated extension connections.
- There is no CVE, no published loss total and no attacker attribution. The exploit details are promised in a later report.
LNbits told operators to stop, then shipped 1.7.0
The warning did not begin with the release notes. On 8 November, at 13:56 Europe/London, the project’s @lnbits account told users to stop their servers immediately “following a wave of attacks,” saying security patches were coming and that it was better to err on the side of caution. Two days later, 1.7.0 is the update those operators were told to wait for.
The news post is explicit about the running order: upgrade to 1.7.0 before running LNbits. That is a stop-then-patch instruction, not a suggestion to apply the package at the next convenient restart. The GitHub release describes 1.7.0 as a critical security release with hardening, vulnerability fixes and added protections across authentication, extension management and payment handling. It also lists new features, including TOTP two-factor authentication, on-chain wallets and BOLT12 payments. Those additions matter, but they are not why this release was published under an urgent banner.
LNbits will, it says, “follow up with full details of the exploit in a separate report.” Until that report appears, operators should work from the recovery steps the project has already set out, not from speculation about how the bug is triggered.
An upgrade does not, by itself, recover a compromised server
If a compromise is suspected, LNbits says to prefer a fresh server and to install 1.7.0 there. Logs and records from the old host should be preserved before it is replaced. The point is straightforward: a patched binary on a machine an attacker may already have used is not the same as a clean install.
Every user key has to be rotated as well. Logged in as Super Admin, operators are told to open Settings → Users, choose Reset Wallet Keys and confirm the action. Existing keys will stop working, and users must update connected apps with the new ones. Funding-source credentials — API keys, macaroons and whatever else the backend uses — should be revoked at the source and replaced in LNbits settings. Any other secrets stored in those settings should be treated as compromised and replaced.
Connected extensions have to be rebuilt, not merely pointed at the new version. LNbits tells operators to revoke or delete existing connections and to create new ones with updated credentials for NWC Provider, LNDHub, Bolt Cards, TPOS, Bleskomat and FOSSA. Skipping that list would leave a path that the key reset was meant to close.
The project also restates a broader operational point: LNbits is a hot wallet, and the credentials needed to spend funds live on an online system. It advises keeping only what is needed for day-to-day operations online and moving excess balances to an on-chain wallet whose spending keys are kept offline. That advice is not a finding about this incident; it is the project’s own description of the risk of running a hot wallet, offered in the same post as the emergency upgrade.
Similar self-hosted bitcoin payment software has had to tell operators that an update is not the same as a clean recovery. BTCPay Server’s recent warning that hot wallets on 2.4.1 and older had been swept is the nearest recent TSN comparison. The same distinction — rotate credentials, rather than treating the old secrets as safe — appeared when GitBook told users to rotate API tokens after an AI-agent attack.
What is known, and what the later report still has to answer
What can be said now is limited, and that limit should stay visible. LNbits has said there is a vulnerability, dated its discovery to 8 November, warned that prior versions put funds at risk, and shipped 1.7.0 as the fix. It has not published a CVE or GHSA, has not given a loss figure, and has not attributed the attacks to a named group or country. The 8 November message spoke only of “a wave of attacks.” None of that should be filled in from unofficial threads.
The recovery steps are, in that light, more important than a technical reconstruction of the bug. A later exploit report may help other projects and forensic work. It should not be waited for before upgrading, and it will not, on its own, tell an operator whether their instance was already abused. The only people who can answer that, in the project’s own framing, are operators who inspect their logs, their balances and their outgoing payments, and who assume that exposed credentials might still work after the package is updated.
That is why the fresh-server instruction and the key reset sit beside the version number rather than below it. Software used as a Lightning accounts system often holds other people’s funds as well as the operator’s own, which raises the cost of treating this as a routine patch. Wallet-drainage incidents in other parts of crypto, such as Bloom’s report that attackers drained 9,408 SOL from 49 users’ wallets, are a reminder that once spending credentials have been used, the loss is already in the ledger. LNbits has not said that has happened here. It has said it could, on unpatched versions.
Until the promised exploit report appears, the identifier to use is simply LNbits 1.7.0. The work for operators remains the sequence the project has set: stop any unpatched instance, install 1.7.0, and if there is any reason to suspect a compromise, rebuild on a new server with new keys and new connections.
Sources
- LNbits, “LNbits 1.7.0: security update and upgrade guidance”, 10 November 2026. https://news.lnbits.com/news/lnbits-1-7-0-security-update
- LNbits, GitHub release v1.7.0, “URGENT SECURITY UPDATE”, published 10 November 2026, 17:09 UTC (17:09 Europe/London). https://github.com/lnbits/lnbits/releases/tag/v1.7.0
- LNbits (@lnbits), post, 8 November 2026, 13:56 UTC (13:56 Europe/London); API-verified. https://x.com/lnbits/status/2119428804951048237
Related stories
BTCPay Server’s warning that hot wallets on 2.4.1 and older had been swept is the closest recent TSN read: another self-hosted bitcoin payments stack telling operators that a vulnerable hot wallet is a funds problem, not only a packaging one.
Also relevant:
- GitBook Users Told to Rotate API Tokens After AI-Agent Attack
- Bloom Says Attackers Drained 9,408 SOL From 49 Users’ Wallets
Follow @tsnmediahub on X for breaking AI news as it happens.
Follow on X
