LNbits 1.7.0 Addresses November 8 Lightning Wallet Attacks

By Marcus Bennett

Between roughly 09:22 and 14:00 UTC on November 8, attackers created unauthorized accounts on the LNbits instance of Telegram tipping service BitTipBot and withdrew 2,285,545 satoshis, according to operator Kevin Ravensberg. The reported loss equaled about 0.0229 BTC. The figure applied only to that instance.

The withdrawal formed part of a wider attack wave that began over the weekend. Multiple reports described unauthorized account creation and fund withdrawals. On November 8, LNbits told users on X to stop their servers immediately after reporting active attacks. The project also disabled instances on its hosted service.

The project was preparing patches when the shutdown instruction went out. LNbits said it was “better to err on the side of caution.” Operators had to complete security checks before reopening services.

By November 10, LNbits had released version 1.7.0 as an urgent security update. The open-source Lightning Network wallet and accounts platform used SECURITY UPDATE as the release label in an official X post linking to the GitHub release. LNbits instructed every operator to upgrade before restarting servers.

Official guidance placed every version before 1.7.0 in scope and warned: “funds running on prior versions of LNbits are at risk of being stolen.” The release contains security fixes for the incident identified on November 8. The project said a full technical report on the exploit would follow. As of the announcement, it had not published an aggregate loss figure across affected instances.

What should operators do now?

For operators who suspect compromise, official guidance calls for a fresh server because updating alone cannot remove access an attacker may already have gained from the system.

The prescribed recovery sequence covers:

• Upgrade to version 1.7.0 before bringing servers back online.
• Rotate all user wallet keys as Super Admin.
• Replace funding-source credentials, including API keys or macaroons.
• Rotate other secrets stored in settings.
• Review or re-create connections for NWC Provider, LNDHub, Bolt Cards, TPOS, Bleskomat and FOSSA.

The list separates wallet rotation from extension review. Operators should not treat the version bump as the entire recovery process. The sequence extends beyond wallet keys into service credentials and external connections. For operators running many integrations, the recovery workload extends well beyond installing a patch.

LNbits describes its wallet as a hot wallet. The project says operators should keep only operational balances online. They should review activity regularly and move excess funds to offline keys.

Inside version 1.7.0

Version 1.7.0 combines incident-driven hardening with a broader product expansion spanning wallet funding, offer payments, authentication, scheduling and unattended extension maintenance across self-hosted and managed deployments.

The GitHub release notes list security hardening across authentication, extension management and payment handling, alongside dependency updates. New capabilities include:

• On-chain wallet support, BOLT12 offer payments and TOTP two-factor authentication.
• NIP-17 support, a job scheduler and automatic extension updates.
• Hold invoice support for the LNbits funding source.

LNbits began in 2019 as a free, open-source project founded by Ben Arc. It later formed a commercial entity to support development. The platform offers multi-user accounts and a large extension suite on top of any Lightning funding source, including LND and Core Lightning.

A September 2024 Bitcoin Magazine profile compared LNbits to WordPress for a Bitcoin Lightning node and cited widespread use among individuals, businesses and node operators seeking accessible Lightning tooling. The software runs through self-hosted deployments and managed instances.

For operators, 1.7.0 is both an incident-response release and a broader software upgrade. It does not replace server rebuilds, key rotation or credential resets when compromise is suspected.

Operators have a pre-restart deadline: install 1.7.0 before reopening any server. Where compromise is suspected, rebuild and rotate credentials first; the promised technical report is the next expected development, and no aggregate loss total has been published.