LNbits Orders Emergency Shutdown After Active Attacks Drain Sats
LNbits issued an emergency systemwide shutdown directive on Nov. 8, 2026, after attackers exploited account-creation and withdrawal functions across multiple instances, draining at least 2,285,545 satoshis from one confirmed victim.
Active exploits forced every LNbits operator offline on Nov. 8; at least 2,285,545 sats confirmed stolen, patches expected within 24-48 hours.
Key takeaways
- LNbits directed all server operators to shut down "IMMEDIATELY" at approximately 13:56 UTC on Nov. 8, 2026, following a wave of attacks exploiting account-creation and withdrawal functions.
- Bittipbot operator Kevin Ravensberg (@KevinR4v) confirmed 2,285,545 satoshis (approximately 0.02285545 BTC) drained from his instance over roughly five hours; he has pledged personal reimbursement, but funds remain frozen.
- Founder Ben Arc expects security patches within 24-48 hours (as of 13:56 UTC Nov. 8; check @lnbits for updates before restarting); the hosted service at my.lnbits.com is also suspended until patches ship.
LNbits, the open-source Lightning wallet and payments platform, issued an emergency shutdown directive at approximately 13:56 UTC on Nov. 8, 2026, ordering every operator to take their instance offline immediately after multiple attacks were confirmed. This is not a "patch when convenient" advisory. The directive is a full stop.
The official LNbits X account (@lnbits) posted:
"All LNbits users should stop their LNbits servers IMMEDIATELY. Please forward this announcement. Following a wave of attacks, we have a number of security patches to push. Until then, it's better to err on the side of caution. Updates to follow soon."
LNbits founder Ben Arc (@arcbtc) reinforced the directive, telling the community patches were expected within 24-48 hours and asking operators to circulate the warning. The hosted service at my.lnbits.com is also suspended, with developers indicating it could resume within 24 hours of a confirmed fix.
How the Attack Unfolded
The first sign of trouble came roughly 80 minutes before the systemwide shutdown, when LNbits flagged a potential vulnerability in its Paywall extension at approximately 12:33 UTC and advised operators to disable it. The subsequent all-instances shutdown suggests the problem was not confined to a single extension.
Bittipbot operator Kevin Ravensberg documented the clearest confirmed loss. According to his X post (@KevinR4v, Nov. 8, 2026), attackers created new accounts on his LNbits instance and withdrew 2,285,545 satoshis (approximately 0.02285545 BTC) between 9:22 a.m. and 2:00 p.m. UTC, a roughly five-hour window. Ravensberg pledged to personally reimburse affected Bittipbot users, but access to funds is restricted until developers ship the patch.
The precise exploit mechanism has not been publicly disclosed. What is confirmed: unauthorized account creation followed by unauthorized withdrawals. Whether the flaw sits in LNbits' core account-management layer or in a specific extension is not yet established.
The Custodial Chain Most Users Never Mapped
Here is the structural problem this attack exposes. Bittipbot users didn't think they were trusting a custodian. They were using a Telegram tipping bot. But they were trusting Ravensberg's LNbits instance, which was trusting the LNbits software stack, running over the public internet with account creation open. That is a three-link custodial chain the average user never mapped. Self-sovereignty requires understanding every link.
LNbits runs on LND and Core Lightning backends and supports dozens of optional extensions: payment terminals, tipping services, APIs, and more. That modularity is the product's core value proposition. It is also exactly what makes securing a public-internet deployment expensive in security overhead. Each extension is additional code surface. The Paywall extension flagged first; the systemwide shutdown followed. The flexibility and the attack surface are the same feature.
This architecture critique holds unless the post-mortem reveals something narrower: an isolated configuration error, a non-default extension misused, or a mis-scoped credential rather than a core account-authorization flaw. If that is what the patch addresses, and an independent audit clears the core stack, the problem is operational rather than architectural. That distinction matters for operators weighing whether to redeploy after the patch ships.
It is also worth noting that LNbits pushed a v1.6.0 security release in September 2026 following an audit by V12. A second major security event within two months warrants more than a patch. It warrants a full re-audit.
The broader Lightning security picture this week is worth tracking without overstating it. Core Lightning issued security updates in early November, and Electrum released v4.8.4 patching a Lightning onion message vulnerability. No confirmed link exists between those events and the LNbits attack. But the density of Lightning-layer security events in a short window is a signal every operator should factor into their threat model.
What Operators Need to Do Right Now
If you run any LNbits instance, it should be offline. Not after you finish reading. Now.
Monitor @lnbits on X for patch announcements. The 24-48 hour estimate was current as of 13:56 UTC on Nov. 8; check for updates before restarting anything. If you hold sats in any LNbits-backed service, assume no access until the patch ships and the operator confirms the instance is clean.
The post-mortem will determine whether the vulnerability was architectural or operational. That answer shapes whether the right response is configuration hardening or a deeper rethink of running LNbits on the public internet at all.
Sources
- LNbits official emergency shutdown post (@lnbits, ~13:56 UTC Nov. 8, 2026)
- Ben Arc (@arcbtc) patch timeline post (Nov. 8, 2026)
- Kevin Ravensberg (@KevinR4v) theft documentation post (Nov. 8, 2026)
- V12 security audit of LNbits (v12.sh/blog/lnbits)
Frequently Asked Questions
Is my underlying Lightning node (LND or Core Lightning) at risk, or only LNbits?
The confirmed attack targeted LNbits account-management and withdrawal functions, not the LND or Core Lightning node layer directly. LNbits sits as a frontend over your node. Shutting down LNbits is the immediate action; your node software itself is a separate surface. That said, until the post-mortem is public, treat the full stack with caution and do not restart LNbits until patches are confirmed.
What is the actual vulnerability, and was it limited to the Paywall extension?
The precise exploit mechanism has not been publicly disclosed as of the shutdown directive. The Paywall extension was flagged first, but the systemwide shutdown indicates the concern extends beyond one extension. Do not assume a Paywall-only fix covers your instance.
If Bittipbot's operator is personally reimbursing users, are those sats safe?
Ravensberg's pledge to reimburse is a voluntary commitment, not a guarantee backed by an insurer or protocol. The affected sats remain inaccessible until the patch ships and the instance is restored. This is the custodial chain in practice: when the platform your funds sit on goes down, your recourse runs through the operator's personal decision, not your own keys.
