LNbits Tells Operators to Shut Down Bitcoin Payment Servers After Wave of Attacks

LNbits, an open-source platform for Bitcoin payments and wallet accounts, has asked all users to stop their LNbits servers after reporting a series of attacks. The project said it had security patches to roll out and would issue further updates, but as of 9 November no explicit clearance to restart had been published.

The instruction applies to both self-hosted operators and customers of LNbits' managed service, which the project said it had already taken offline as a precaution.

What LNbits has said so far

The project has issued two separate notices. The first, dated 8 November, said LNbits had disabled every instance on its hosted service as a precautionary step and expected services to come back within 24 hours. The second, broader warning asked all users, regardless of how they run the software, to stop their servers.

According to CryptoSlate, which reviewed the project's public material at about 18:20 UTC on 9 November, the hosted shutdown is attributed to the official LNbits account, and the 24-hour restoration window was framed only as an estimate. Neither notice announced that servers were safe to restart, and no all-clear appeared on the project's public timeline.

LNbits has not, in the material reviewed, described the nature of the attacks in detail, how many operators were affected, or whether any funds were lost. Those gaps matter for businesses deciding how to respond.

Who is affected and how

LNbits positions itself as a toolkit for merchants, creators and developers who want to accept Bitcoin over the Lightning Network. According to the project's own description, its features include tipping, donation buttons, online checkout, point-of-sale tools, user wallets and application programming interfaces (APIs). It sits on top of an underlying Lightning funding source, meaning it acts as an accounts and payments layer rather than a node in its own right.

That design is part of its appeal. A single Lightning node can back many LNbits wallets, letting an operator offer separate accounts to staff, customers or community members. It also means that taking an LNbits instance offline can halt a range of services at once, from a shop's checkout page to a streamer's tipping button.

The two hosting models now face different situations:

• Self-hosted operators are being asked to stop the instance they run themselves, and the decision to restart rests with them once they judge it safe.
• Hosted customers depend entirely on the provider, which says it has already disabled their instances and will bring them back.

In both cases, the practical effect is the same: payment, checkout and tipping flows routed through LNbits may be interrupted while operators wait for fixes and clear guidance.

The patch question

The most important unresolved issue for operators is which version of the software actually addresses the incident. As of 9 November, GitHub's latest-release interface still listed v1.6.2 as the most recent stable release of LNbits. That version was published on 18 September, and its release notes describe a hotfix for PostgreSQL backups, not a security response to the recent attacks.

On 9 November, LNbits merged pull request #4310 into its development branch. The descriptions attached to that change cover strengthened request protections, blocking the server from sending requests to itself, and switching off new-account creation by default.

Those changes are suggestive. Preventing a server from calling itself is a common defence against server-side request forgery, a class of attack in which a malicious request tricks an application into reaching internal resources it should not expose. Disabling open account creation by default would also narrow the surface available to anyone probing a public instance. However, CryptoSlate noted that PR #4310 has not been established as the remedy for the attacks, and a merge into a development branch is not the same as a stable, tested security release.

For operators running production payment systems, that distinction is significant. Development branches can contain incomplete or untested work, and moving a live merchant setup onto one carries its own risks. A formal tagged release, accompanied by notes explaining what was fixed, is typically what cautious operators wait for before redeploying.

Why it matters for Lightning infrastructure

The episode highlights a recurring tension in Bitcoin's payments layer. Much of the tooling that makes Lightning usable for small businesses and individuals is open source and maintained by relatively small teams. That keeps costs low and gives users the option to run everything themselves, but it also means security incidents can ripple quickly across many independent deployments.

Self-hosting is often presented as a safeguard, because it removes reliance on a single custodian. Yet when the vulnerability lies in shared software, every self-hosted instance may be exposed at once, and each operator must act individually. A blanket instruction to stop servers is a blunt but understandable response when a project cannot yet be confident that its users are protected.

The hosted service raises a different consideration. Customers there benefit from the provider taking action on their behalf, as LNbits says it has done, but they have no independent way to restore service and must rely on the project's timetable. The 24-hour estimate given on 8 November had not, on the evidence reviewed by CryptoSlate, been followed by a confirmed restoration or restart clearance by the afternoon of 9 November.

LNbits also functions as an accounts layer that can hold balances for multiple users on one node. That makes the security of the software particularly sensitive: a weakness that lets an attacker manipulate requests or create accounts could, in principle, expose more than one user's funds. The project has not said whether any such losses occurred.

Risks and open questions

Several uncertainties remain. The project has not publicly detailed the attack vector, so operators cannot easily assess whether their particular configuration was vulnerable. The absence of a stable release means there is no officially sanctioned version to upgrade to. And without an explicit all-clear, any operator who restarts early is acting on their own judgement.

There is also a reputational dimension. Merchants who adopted Lightning payments for speed and low fees may be less patient with extended outages, particularly if they lack the technical capacity to follow development-branch changes. Clear, timely communication from the project will shape how many return once services resume.

On the other hand, the decision to shut down proactively rather than leave instances running suggests the maintainers are prioritising user safety over uptime, which is generally regarded as the right instinct in a live security incident.

What to watch next

Operators effectively face two separate questions: which released version of LNbits fixes the problem, and at what point the project will formally confirm that servers can be switched back on. Until both are answered, the safest reading of the guidance is that instances should remain offline.

The next signals to watch are a new tagged stable release on GitHub with security-focused notes, confirmation of whether the changes in PR #4310 form part of the fix, and a formal notice telling self-hosted and hosted users they can resume. Any post-incident disclosure explaining what happened and whether funds were affected would also help users judge the scale of the problem.