LNbits Orders All Server Operators to Shut Down After Attacks

LNbits has instructed every operator running its software to shut down their servers after a series of attacks against instances of the Lightning Network account-management toolkit. The project also disabled all instances on its managed hosting service, my.lnbits.com, as a precaution, and said services would resume within 24 hours.

The scope of the instruction matters. It applies to LNbits servers, not to every node on the Lightning Network. The software itself lets operators create wallets and payment applications on top of a connected funding source, and its documentation lists backends including LND and Core Lightning. Nothing in the shutdown notice exempted any particular funding-source configuration — every LNbits deployment was told to stop.

How did the warning escalate?

The shutdown order did not come out of nowhere. LNbits had already asked operators to disable the Paywall extension immediately while developers investigated a potential bug. That first warning targeted a single extension. The subsequent instruction widened to cover all LNbits servers, including installations that never touched Paywall.

The escalation signals the developers could not rule out exposure beyond the original suspect component. The shutdown notice did not identify which versions are vulnerable, did not explain the attack route, and did not state a total loss amount across affected instances. That leaves operators working with incomplete information until the project ships fixes.

What did the attack actually do?

One operator has published a first-hand account of the damage. Kevin Ravensberg wrote on X that about 2.29 million satoshis had been withdrawn from his LNbits instance by newly created accounts before he could stop the server. That detail — fresh accounts draining funds directly — suggests the attackers exploited the wallet-creation flow rather than compromising a backend node.

Ravensberg pledged to make users of BitTipBot, a service running on his instance, whole. But he told them they would be unable to access funds until LNbits patches the vulnerabilities. His situation illustrates the operational reality of the incident: even operators who intend to cover losses can't move funds while the software remains unpatched and servers stay down.

Where is the fix?

At publication, the project's GitHub releases page still listed v1.6.2 — a PostgreSQL backup hotfix released Sept. 18 — as its latest release. No release addressing the attacks was listed yet.

LNbits contributor Ben Arc gave a concrete timeline: patches "should be merged and available within 24-48hrs." That window is the operative deadline for the ecosystem. Until those patches land and operators verify them, every LNbits deployment faces a standing instruction to remain offline, and managed-hosting customers on my.lnbits.com wait for the service's promised restoration within 24 hours.

What does this mean for operators?

The immediate consequence is a service outage across the LNbits footprint, with any application built on the toolkit — paywalls, tipping services, wallet frontends — dark until further notice. The financial exposure appears concentrated in instances that were online before the warning, though the absence of a stated total loss figure means the full impact isn't yet measurable.

The near-term checkpoint is Arc's 24-to-48-hour patch window. If the fixes merge on schedule and the managed hosting comes back online as promised, operators face the follow-on task of upgrading before restarting — and deciding how to make users whole in cases like Ravensberg's, where 2.29 million satoshis left the instance before anyone could pull the plug.