LNbits 1.7.0 Fixes Vulnerability Affecting All Earlier Versions

By Daniel Okafor

LNbits released version 1.7.0 as a security update for a vulnerability the project says affects every earlier version, while a user reported that an attacker stole about 0.023 bitcoin (BTC) from an LNbits instance.

The open-source Bitcoin wallet and payments platform for the Lightning Network urged all operators to install the update immediately. Its warning was direct: “The upgrade alone does not protect credentials that may already be exposed.”

What does version 1.7.0 address?

LNbits said the vulnerability affects every version released before 1.7.0. The warning covers the project’s full pre-1.7.0 release history, rather than a limited group of older versions. For operators, the immediate software response is to install 1.7.0 immediately.

The release addresses the vulnerable software. It does not, however, remediate credentials that attackers may already have obtained. LNbits explicitly separated installation of the fix from the work required to respond to possible exposure.

What should operators do if exposure is suspected?

Operators should treat the patch and any security response as separate actions. LNbits set out three instructions:

• Install version 1.7.0 immediately. Every operator running a pre-1.7.0 release falls within LNbits’ stated scope.
• Reset wallet keys and replace related credentials if they may have been exposed. This step targets credentials that an attacker could already have obtained, which the software update cannot undo.
• Migrate the server if compromise is suspected. LNbits reserves this guidance for operators who believe an instance may have been compromised.

These steps answer different questions. The update covers vulnerable software; key resets and credential replacement cover exposed credentials; server migration covers suspected compromise. An operator does not need to suspect a full compromise to reset potentially exposed keys, while an operator who suspects compromise is urged to go further and migrate the server.

That distinction is central to LNbits’ warning. Even after an operator installs 1.7.0, credentials exposed beforehand remain exposed unless they are reset. Treating version 1.7.0 as the entire remedy would leave the exposure problem unaddressed, which is why the project says the update alone may not protect affected wallets.

Why does patching alone not finish the response?

LNbits’ guidance states: “Key resets and credential replacement address exposed credentials, while server migration is recommended when compromise is suspected.” The wording distinguishes two levels of response: credential rotation covers possible exposure, while migration addresses suspected compromise of the instance itself.

The practical consequence is that a suspected compromise requires action beyond patching and credential replacement: the server itself should be migrated. The update addresses the vulnerable software, but it does not change credentials that may already have leaked.

What happened in the reported theft?

A user reported that an attacker used an LNbits instance to create a new account and steal about 0.023 BTC. That places the reported loss at the instance level, with account creation preceding the theft described by the user.

LNbits said the losses affected both users and the LNbits team. The project is working on a response. That places the incident inside the platform’s operations: operators face an urgent upgrade and may need to reset wallet keys and replace credentials, while any operator who suspects compromise is urged to migrate the server.

The reported 0.023 BTC theft gives the warning immediate operational significance without establishing the full scale of the losses. The figure describes the theft the user reported; it is not presented as the project’s total loss. The remediation burden is broader because the vulnerability warning applies to every LNbits version before 1.7.0.

LNbits set no future deadline for the upgrade: it says to install the update immediately. The immediate priority is to close three separate risks, with software exposure addressed by the patch, leaked credentials repaired by resets and suspected compromise addressed through server migration.