LNbits 1.7.1 reaches PyPI after the 1.7.0 security release
Source report: 2026-11-11 · Editorial analysis published: 2026-11-11
The November 11 package follows the stable security release. LNbits’ recovery advisory also calls for replacing credentials used by wallets, funding sources and connected apps.
A follow-up package is on PyPI
LNbits 1.7.1 reached PyPI on November 11 at 13:41 UTC, a day after the stable 1.7.0 security release. The 1.7.1 source tag is visible in the project’s GitHub repository. At our check, the latest published GitHub release was still 1.7.0. The project’s operator advisory names 1.7.0 as the minimum version to run after the November 8 vulnerability.
PyPI records the package upload for users who install through Python. GitHub’s comparison of the two tags includes disabling the default paid-review endpoint for extensions. That is part of the follow-up changes. The incident advisory and the separate credential recovery steps still explain how the project wants operators to respond.
The stable release is available
LNbits published stable version 1.7.0 on November 10. It tells operators to install it before running their LNbits service following the vulnerability disclosed on November 8. PyPI lists the stable package upload at 16:20 UTC, and GitHub lists the release at 17:09 UTC. These are separate publication channels for the same stable version. The release candidate covered earlier was a test package.
LNbits helps services manage Bitcoin payments, including Lightning payments that move off the main chain. A miner who receives pool payouts through a service built on LNbits may depend on that service to create an invoice or credit a payment. The release gives an operator a version to deploy and a recovery plan. The status of a particular payout service still depends on its own operator.
Replace access in each place it was used
The advisory calls for rotating all user wallet keys. It gives a control for the instance’s super administrator under Settings, Users, Reset Wallet Keys. Rotating means cancelling the old keys and issuing replacements. Once reset, the old credentials stop working. Connected apps need the new keys to regain access, so an app failure during this transition can reflect an intentional reset.
The funding source also needs attention. It is the backend that actually handles the money, for example a Lightning node. An operator revokes the backend’s old API credential at the source, obtains a replacement and updates the setting in LNbits. Some backends use a macaroon, a credential that grants specified access to a node. Resetting an LNbits wallet key does not revoke that separate credential.
Deal with possible access to the server
The project prefers a fresh server when compromise is suspected. It asks operators to preserve relevant logs and records before replacing the old server, then install 1.7.0 on the new one. A software update changes what the program runs. Someone who previously gained access to the server or copied a secret may still have that access until the operator deals with it.
LNbits also advises replacing other sensitive credentials stored in its settings and rebuilding extension connections. It lists examples including NWC Provider and LNDHub, which can connect wallets or apps to the payment system. Those integrations need revoking and reconnecting with updated credentials. For an operator, the recovery record can identify which service used which key and when the old access stopped.
What a payout user can actually verify
A pool user generally sees the pool’s account page, an invoice and a receiving wallet. If the operator pauses payments to work on LNbits, the pool’s status page or support notice gives the relevant reopening information. The software release confirms that an update is available. It does not settle an existing payout or confirm when a particular provider will resume sending money.
After a provider confirms service is back, the pool’s payout history and the receiving wallet help locate the result. An invoice can have been created while payment is still pending. An operator who has reconnected a wallet integration can verify a small controlled payment before opening it for normal use. That checks the current path after the keys and settings have changed.
Check the package and the environment
PyPI lists Python 3.10 or newer, below 3.14, for the 1.7.0 package. That matters to operators who install through Python. A deployment that still runs in an older environment may need an environment change before it can load the package. Check the version reported by the running service after updating. A file downloaded on the server tells you what is available to install, while the running version tells you what currently handles payments.
The stable release also lists time-based two-factor authentication. A short login code can add a check to account sign-in. Backend credentials and application keys are separate paths into the system. Review what each connected service needs before restoring it, so an application can return with the permissions required for its job.
What remains to be published
LNbits describes 1.7.0 as the release with fixes responding to the incident. The advisory says it will publish full details of the exploit separately. The current documents support the version requirement and the recovery steps. They do not give a complete account of what happened to an individual account or say which deposits a provider will return.
The project also reminds operators that LNbits is a hot wallet system. The credentials needed to make payments are available to an online service, which is convenient for regular operations. Its guidance is to keep only what those operations need online, review balances and outgoing payments, and move excess funds to a wallet with offline spending keys.
Source: LNbits / PyPI, GitHub and operator advisory ↗ · LNbits v1.7.0 stable GitHub release ↗ · LNbits v1.7.0 to v1.7.1 source comparison ↗ · LNbits security and recovery advisory ↗ · LNbits 1.7.0 on PyPI ↗ · ASIC.tools coverage of the earlier release candidate ↗
Mining calculator ↗
