LNbits tells every operator to shut down their Lightning wallet servers amid a wave of attacks
On November 8, 2026, the LNbits project asked everyone running its self-hosted Lightning wallet to switch their servers off, after an exploit drained 2,285,545 satoshis from one operator before a fix shipped. If you self-host LNbits, take the exposed instance offline and disable extensions until the patches land.
November 8, 2026. The LNbits project tells every operator of its self-hosted Lightning wallet to switch their servers off, in the face of a wave of attacks. 12:33 UTC. A first, narrower warning asked only that the Paywall extension be disabled. November 9, 09:00 UTC. No patched release had shipped yet. Why it matters: self-hosting a Bitcoin wallet inverts the trust model — and when a flaw strikes, the shutdown notice becomes, on its own, the entire incident-response plan.
An exploit that drained 2,285,545 satoshis before the fix
LNbits is a free, open-source Lightning Network wallet you install on your own machine or server. Where most wallets hand the funds to a custodian, LNbits hands custody to the owner: you hold the keys, you run the node, you own the security. That is the self-hosted promise applied to money — and it is exactly why an incident like this cannot be fixed by a vendor pushing a remote update.
The attack is not hypothetical. Kevin Ravensberg, the operator of the BitTipBot Telegram bot, said his server was exploited before the shutdown notice went out. Freshly created accounts used an exploit to withdraw 2,285,545 satoshis — roughly 0.023 bitcoin — before he could stop it. The attack ran from 09:22 to 14:00 UTC on November 8, more than three hours before the project’s first warning at 12:33 UTC.
Ravensberg has promised to repay BitTipBot users, whose funds remain locked until the flaws are fixed. In a later post he said that developer Ben Arc and a team of security testers had confirmed “which exact extension exploit was used” on his server — but neither he nor the project had named that extension publicly as of November 9, 09:00 UTC.
A tight timeline: two notices in eighty minutes
The sequence of events reads as a project that first hoped to contain the problem, then changed course within an hour and a half.
On November 8 at 12:33 UTC, LNbits issued a first warning asking operators to disable the Paywall extension, an add-on that charges users to view content, while it investigated a possible bug. About eighty minutes later, that message was replaced by a far broader instruction: switch off every server. The project said it had several security fixes to release and asked operators to stay careful until they were out.
The same day, LNbits switched off all the instances it runs itself on its hosted service my.lnbits.com, promising they would be back within twenty-four hours, around 17:20 UTC on November 9. The contrast is instructive: a hosted provider can decide on its own to cut its services. A self-hosted operator has to read the notice, realize it applies, and act on their own machine — each step adding to reaction time.
As of 09:00 UTC on November 9, the project had still not shipped a patched version, had not cancelled the notice, and had not explained how to check whether a server had been hit before being taken down. Ben Arc estimated the patches would be merged and available within twenty-four to forty-eight hours, placing the window between 14:00 UTC on November 9 and 14:00 UTC on November 10.
What is at stake: a Lightning wallet is not a blog
The contrast with most self-hosted incidents deserves to be spelled out. When a Nextcloud or Jellyfin instance is compromised, the damage is data or compute time. When a Lightning wallet is compromised, what leaves is programmable cash, and it leaves irreversibly and pseudonymously. Lightning transactions are instant and cannot be recalled: once the satoshis move, there is no support desk and no chargeback.
That asymmetry changes the security burden. An LNbits extension is not a convenience module: it is an attack surface that reaches directly into funds. The first warning named Paywall, suggesting the vulnerability sat in an extension — third-party code, less reviewed than the core, yet running with the wallet’s privileges. It is the classic self-hosted pattern pushed to its limit: the modularity that makes a tool useful is also what widens its surface.
This is not the first time this blog has documented the risk on the Lightning ecosystem. In September, Alby disclosed a critical flaw that drained Alby Hub wallets exposed to the Internet, as detailed in our analysis of Alby Hub. The lesson repeats almost verbatim: public exposure of a self-hosted wallet turns a software flaw into an immediate financial loss.
A custodial service can be patched centrally and its users notified; a self-hosted fleet cannot. That is why the project’s move to issue a shutdown notice — the bluntest instruction a wallet can give — is itself informative: it prioritises stopping the bleed over preserving uptime, and it accepts that every operator is now on their own for verification. For a community that values sovereignty, the notice is a reminder that sovereignty is a liability as well as a feature: the same control that frees you from a custodian also frees the project from any obligation — or ability — to fix your server for you.
Why public exposure is the risk multiplier
The same exploit against an LNbits instance confined to a local network would not have drained much. What turns an extension bug into a financial loss is public exposure: an instance reachable from the Internet by anyone, with weak authentication and active extensions. That is exactly the configuration Ravensberg ran to serve BitTipBot to hundreds of users on Telegram — a public service, and therefore a public surface.
The boundary is visible in the two notices of November 8. The first named one extension, Paywall; the second named every server. In between, the project realized the problem was not “one extension” but “extensions running on exposed servers” — hence the radical instruction to switch off rather than hot-patch.
It is also worth separating the wallet from the node. The shutdown notice covers LNbits servers and says nothing about Lightning nodes or other wallet software: a bare LND or Core Lightning node is not covered by this instruction. Anything exposing an LNbits interface — the application that manages keys and channels — is.
In practice, an operator forced to cut service without a patch is in an awkward spot: offline, they can neither receive nor check in real time. The only verification left is after the fact, on logs and channel state: spotting abnormal outbound payments in the attack window, comparing channel state before and after, and revoking any node key that may have been compromised. That audit does not end at restart.
Verdict
If you run an LNbits instance, the reflex is not to “monitor” but to switch off. Cut the instance’s Internet access, disable extensions — Paywall first — and wait for the fixes Ben Arc announced, expected by November 10 at the latest. Only restart after applying the patched version and confirming your node did not serve as an exit channel during the attack window. If you host a Lightning service for others, like BitTipBot, prepare for the repayment question: in a self-hosted model, the operator — not the project — carries the loss. And more broadly, treat any self-hosted Lightning wallet as an Internet-facing financial system: network segmentation, VPN-only access, and one simple rule — no extension is “harmless” once it touches funds. The strong signal of this incident is that the immediate remedy was not a patch but an emergency shutdown: when the fix is still on its way, the only defence left is to cut the power.