LNbits has released version 1.7.0 as an urgent security update following reported Bitcoin wallet thefts. As of November 11, 2026, the project's official release tells all LNbits users to update immediately and identifies security changes across authentication, extension management and payment handling.
The incident draws attention to the software connecting Bitcoin balances to everyday payment tools. An operator can control the underlying funding source while still depending on an internet-connected application to process payments safely. Maintaining that application is part of protecting the money it can spend.
An emergency release across the payment stack
The official GitHub release was published on November 10 at 17:09 UTC. LNbits calls it a critical security release and urges operators to prioritize installation.
Its scope extends beyond a single payment function. The release includes vulnerability fixes and additional protections, alongside authentication changes. It also adds a superuser function for resetting all wallet keys, plus TOTP two-factor authentication and automatic extension updates at startup or on a schedule.
Those additions give administrators more tools for managing access and maintenance. The release notes, however, do not explain which individual change closes the route used in the reported thefts.
For operators, the immediate instruction is explicit: LNbits has called for an emergency upgrade. Treating the release as an optional feature update would miss the reason it was published.
The presence of new functionality in the same package can complicate installation planning. Administrators normally assess whether an upgrade changes their workflow before installing it. Here, that assessment needs to happen within an urgent security response, with attention to the payment integrations the installation actually uses.
Server ownership and control of funds are separate questions
LNbits supports multiple funding arrangements. Its documentation distinguishes between self-custodial backends, including LND and Core Lightning, and services where a provider manages the funds. Another LNbits instance can itself be the funding source.
That flexibility means two people using the same LNbits interface may have different custody arrangements.
Someone running LNbits against their own node controls more of the system and takes on its maintenance. Someone using another operator's instance depends on that operator to install updates and administer access. Choosing a different backend can change that relationship without changing the applications, users or extensions above it.
For readers comparing ways to retain control of their funds, the practical question extends beyond ownership of a recovery phrase. Which software can authorize spending, and who maintains it?
Running a server yourself places both the upgrade decision and responsibility for carrying it out in your hands. A user of a hosted installation may have no equivalent administrative access.
That difference should shape communication during a security incident. An operator needs deployment guidance. An ordinary account holder needs confirmation from the person running the service about its status and the actions required of users. Sending both groups the same instruction to “update” leaves an operational gap.
Payment tools make the consequences tangible
LNbits describes its software as a modular payment system with optional extensions. Its stated uses include point-of-sale payments, online checkout, donation buttons and tipping. It also supports vending machines and other hardware.
These connections explain the stakes beyond a wallet balance. A security response can affect a checkout integration or a device expecting the server to process a payment.
Consider the operational choices a merchant using LNbits for checkout would face. Pausing the service during remediation would require a decision about accepting payments through another route. A tipping service would face a different problem: explaining availability to people who interact through a connected application rather than the server itself. These examples illustrate consequences of the deployment model rather than reported outcomes for specific LNbits businesses.
The modular structure also gives administrators a concrete review task. They can identify which extensions and connected applications their operation needs, then check those workflows during the upgrade. A successful server restart alone would answer only part of the operational question. The payment path customers use still needs to work.
Readers following wallet login suspensions after unauthorized transactions will recognize the distinction between restoring access and completing a security response. For an LNbits operator, software maintenance and service continuity meet in the same installation.
Overview
LNbits has shipped version 1.7.0 under an urgent security banner after reported wallet thefts. Its official release calls for immediate updates and includes protections across authentication, extensions and payments.
The custody implications depend on the installation. LNbits can connect to an operator's own funding source or to a provider-managed service, so responsibility for applying the patch varies. The project's instruction is directed at everyone running the software: update to version 1.7.0 immediately.
