LNbits Lightning Wallet Servers Under Active Attack: Shutdown Order, Detection, and Hardening Guide

The LNbits project has issued an unusually blunt directive: every operator running an LNbits server should shut it down now. This is not a routine 'update when convenient' advisory. The maintainers have acknowledged a wave of active attacks against self-hosted LNbits instances and stated that multiple security fixes are pending release — but are not yet available. Until those patches ship, there is no in-band defense; the only recommended mitigation is to take the service offline.

LNbits is a free, open-source Bitcoin Lightning wallet and accounts system. It is popular with hobbyists, merchants, developers, and small payment operators because it lets anyone spin up a multi-account Lightning wallet server on top of a funding source (LND, Core Lightning, LNPay, etc.). That ease of deployment is also the risk: LNbits instances frequently hold real, spendable Bitcoin in custodial hot wallets, are exposed directly to the internet, and are often run by operators without a security team.

The financial impact is already confirmed. One operator reported that newly created accounts abused a security issue to withdraw 2,285,545 satoshis (≈0.023 BTC) from his server before he could react. That is a modest sum in absolute terms, but the pattern matters: attackers are systematically creating accounts, exploiting a server-side flaw, and draining custodial balances. If you run LNbits, your hot wallet is the target.

Technical Analysis

What Is Affected

• Product: LNbits — open-source Lightning wallet/accounts server (Python, typically deployed via poetry/uvicorn or Docker, commonly listening on port 5000)
• Deployment model: Self-hosted instances, frequently internet-exposed, backed by a Lightning node funding source
• Versions: The project has indicated fixes are forthcoming; treat all currently deployed versions as vulnerable until patched releases are published and you have applied them
• CVE status: No CVE identifier has been published in the advisory as of this writing. Do not wait for a CVE to act — the exploitation is happening now

How the Attack Works (Defender's View)

Based on the operator report and the project's warning, the observed attack chain is:

1. Reconnaissance — attackers scan for publicly reachable LNbits instances (default port 5000, recognizable web UI/API responses)
2. Account creation — LNbits by design allows self-service account/wallet creation; attackers register new accounts programmatically
3. Abuse of a server-side security issue — the new accounts leverage a flaw in the LNbits application layer to move funds they do not own
4. Withdrawal — funds are paid out via Lightning invoices (BOLT11) from the server's custodial funding wallet to attacker-controlled destinations

The key defensive insight: the theft is executed through legitimate-looking application API calls. There is no shell being spawned, no malware dropped — the 'exploit' is authenticated (self-registered) abuse of LNbits' own payment functionality, specifically its withdrawal paths (e.g., /api/v1/payments, the withdraw extension endpoints). That means network and endpoint detections must focus on application behavior: bursts of new wallet registrations, withdrawal volumes that exceed baseline, and outbound Lightning payments to novel destinations.

Exploitation Status

• Active exploitation: CONFIRMED. The project's shutdown directive and at least one publicly reported theft (2,285,545 sats) establish in-the-wild abuse.
• Patch status: Fixes are announced but not yet released at the time of the advisory. There is currently no patched version to upgrade to — hence the shutdown order.
• CISA KEV: Not listed at time of writing (LNbits is not typical KEV fare), but the absence of a KEV entry does not reduce the urgency for operators holding funds.

Detection & Response

If you cannot shut down immediately (e.g., you need to preserve evidence or drain funds safely first), you need visibility into whether your instance has already been hit. The detections below target the observable behaviors of this campaign: mass account/wallet creation, anomalous withdrawal activity, and post-compromise actions on the host.

Sigma Rules

---
title: LNbits Server Process Spawning Unexpected Child Processes
id: 3f9a1c74-2b6e-4d58-9a31-7c2e5f0b8d44
status: experimental
description: Detects the LNbits Python/uvicorn process spawning shells or system utilities, indicating post-exploitation activity beyond application-layer fund theft on a Lightning wallet host.
references:
  - https://thehackernews.com/2026/11/lnbits-urges-all-operators-to-shut-down.html
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/11/06
tags:
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentCommandLine|contains:
      - 'lnbits'
      - 'uvicorn'
  selection_child:
    CommandLine|contains:
      - '/bin/sh'
      - '/bin/bash'
      - 'curl '
      - 'wget '
      - 'nc '
      - 'python3 -c'
      - 'base64'
  condition: selection_parent and selection_child
falsepositives:
  - Legitimate LNbits extension behavior invoking external tools (rare); validate against change records
level: high
---
title: Suspicious Mass Account or Wallet Creation Against LNbits API
id: 8b2e6d91-4c7a-4f3b-b2e8-1d9a5c6f7e02
status: experimental
description: Detects high-frequency POST requests to LNbits account and wallet creation endpoints, consistent with the reported attack pattern of registering new accounts to abuse a server-side flaw and drain custodial funds.
references:
  - https://thehackernews.com/2026/11/lnbits-urges-all-operators-to-shut-down.html
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/11/06
tags:
  - attack.persistence
  - attack.t1136
logsource:
  category: webserver
  product: linux
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains:
      - '/api/v1/account'
      - '/api/v1/wallet'
      - '/usermanager/api/v1/users'
      - '/usermanager/api/v1/wallets'
  condition: selection
falsepositives:
  - Normal user onboarding; investigate request rate, source IP diversity, and subsequent payment activity
level: medium
---
title: High-Volume Outbound Payment Requests on LNbits Instance
id: 5c1d8e42-9f3b-4a6d-8e71-2b4c9a0d6f55
status: experimental
description: Detects bursts of outbound payment/withdrawal requests against LNbits payment endpoints, matching the reported theft pattern where attackers drain the server's Lightning funding wallet via BOLT11 invoice payments.
references:
  - https://thehackernews.com/2026/11/lnbits-urges-all-operators-to-shut-down.html
  - https://attack.mitre.org/techniques/T1657/
author: Security Arsenal
date: 2026/11/06
tags:
  - attack.impact
  - attack.t1657
logsource:
  category: webserver
  product: linux
detection:
  selection:
    cs-method: 'POST'
    cs-uri-stem|contains:
      - '/api/v1/payments'
      - '/withdraw/api/v1/'
  condition: selection
falsepositives:
  - Legitimate merchant payout batches; correlate with newly created wallets and unfamiliar source IPs
level: high

KQL — Microsoft Sentinel (Syslog/CEF Ingestion)

Most LNbits hosts are Linux boxes forwarding syslog, or Docker hosts whose container logs can be shipped to Sentinel. This query hunts for the campaign's signature pattern: new account/wallet creation followed within a short window by outbound payment activity from the same source.

// Hunt: LNbits account creation followed by payment/withdrawal bursts (Sentinel, Syslog ingestion)
let lookback = 7d;
let AccountCreation =
Syslog
| where TimeGenerated >= ago(lookback)
| where SyslogMessage has_any ("/api/v1/account", "/api/v1/wallet", "usermanager/api/v1")
| where SyslogMessage has "POST"
| extend SrcIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| summarize AccountCreations = count() by SrcIP, bin(TimeGenerated, 1h);
let Payments =
Syslog
| where TimeGenerated >= ago(lookback)
| where SyslogMessage has_any ("/api/v1/payments", "withdraw/api/v1")
| where SyslogMessage has "POST"
| extend SrcIP = extract(@"(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})", 1, SyslogMessage)
| summarize PaymentRequests = count() by SrcIP, bin(TimeGenerated, 1h);
AccountCreation
| join kind=inner Payments on SrcIP, TimeGenerated
| where AccountCreations >= 3 or PaymentRequests >= 5
| project TimeGenerated, SrcIP, AccountCreations, PaymentRequests
| order by TimeGenerated desc;

A second, simpler sweep for identifying internet-exposed LNbits instances in your estate:

// Identify hosts accepting connections on the LNbits default port 5000
DeviceNetworkEvents
| where TimeGenerated >= ago(7d)
| where LocalPort == 5000
| where ActionType == "InboundConnectionAccepted"
| summarize RemoteIPs = dcount(RemoteIP), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, LocalIP, InitiatingProcessFileName
| order by RemoteIPs desc;

Velociraptor VQL

For DFIR triage of a suspected LNbits host, this artifact identifies the running service, its listening exposure, and recently modified wallet database files (LNbits stores accounts and transaction records in SQLite by default under its data directory).

-- Triage LNbits host: running service, exposure, and wallet DB artifacts
LET processes = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'lnbits|uvicorn' OR Name =~ 'uvicorn|lnbits'

LET listeners = SELECT Pid, Name, Laddr, Lport, Raddr, Rport, Status
FROM netstat()
WHERE Lport in (5000, 5001) AND Status =~ 'LISTEN'

LET dbs = SELECT FullPath, Size, Mtime, Atime
FROM glob(globs=['/**/lnbits/data/**/*.sqlite3', '/**/.lnbits/**/*.sqlite3', '/root/lnbits*/**/*.sqlite3', '/home/*/lnbits*/**/*.sqlite3'])
WHERE Mtime > now() - 604800

SELECT * FROM processes
UNION ALL
SELECT Pid, Name, Laddr as CommandLine, Lport as Exe, Raddr as Username, Rport as CreateTime FROM listeners

-- Inventory recently modified LNbits SQLite wallet databases for forensic review
SELECT FullPath, Size, Mtime
FROM glob(globs=['/**/lnbits*/**/*.sqlite3', '/**/.lnbits/**/*.sqlite3'])
WHERE Mtime > now() - 604800
ORDER BY Mtime DESC

Pull the SQLite databases and query the apipayments table for outbound payments (outgoing = true) ordered by time — compare against your expected payout activity. Newly created wallets in wallets/accounts with immediate large outbound payments are the theft pattern.

Remediation & Verification Script

Run this on any Linux host suspected of running LNbits. It stops the service, preserves evidence, and audits the wallet database for suspicious withdrawal activity.

#!/bin/bash
# LNbits Emergency Response — stop service, preserve evidence, audit withdrawals
echo "[*] Identifying LNbits processes..."
pgrep -af "lnbits|uvicorn" | tee /tmp/lnbits_procs.txt

echo "[*] Stopping LNbits services..."
systemctl stop lnbits 2>/dev/null
systemctl stop docker 2>/dev/null && echo "Docker stopped (containers halted)"
pkill -f "uvicorn.*lnbits" 2>/dev/null

echo "[*] Verifying shutdown — port 5000 should show nothing:"
ss -tlnp | grep -E ':5000|:5001' || echo "[OK] No LNbits listener found"

echo "[*] Preserving evidence (copy, do not move)..."
TS=$(date +%Y%m%d_%H%M%S)
mkdir -p /tmp/lnbits_ir_$TS
find / -path /proc -prune -o -name "*.sqlite3" -path "*lnbits*" -print 2>/dev/null | while read db; do
  cp --parents "$db" /tmp/lnbits_ir_$TS/ 2>/dev/null
  echo "[+] Copied $db"
done
journalctl -u lnbits --since "7 days ago" > /tmp/lnbits_ir_$TS/lnbits_journal.log 2>/dev/null

echo "[*] Auditing outbound payments from wallet DB (suspicious recent withdrawals)..."
find /tmp/lnbits_ir_$TS -name "*.sqlite3" | while read db; do
  echo "=== $db ==="
  sqlite3 "$db" "SELECT time, wallet, amount/1000 || ' sats' AS amount, memo FROM apipayments WHERE outgoing = 1 ORDER BY time DESC LIMIT 50;" 2>/dev/null
done

echo "[*] Auditing recently created wallets..."
find /tmp/lnbits_ir_$TS -name "*.sqlite3" | while read db; do
  sqlite3 "$db" "SELECT id, name, user, adminkey FROM wallets ORDER BY rowid DESC LIMIT 25;" 2>/dev/null
done

echo "[DONE] Evidence staged at /tmp/lnbits_ir_$TS — keep the host offline until patched LNbits releases are available."

Remediation

This is a custodial-funds emergency, so sequence matters. Do not simply reboot into a patched version later without first securing funds and checking for compromise.

1. Shut down the LNbits service immediately — this is the explicit directive from the LNbits project. Stop the systemd unit, container, or process. Verify port 5000 (or your configured port) is no longer listening.
2. Move funds off the funding source. The underlying Lightning node wallet is the real prize. While LNbits is down, transfer remaining balances from the node's hot wallet to cold storage or a wallet you fully control. Do not bring LNbits back up against a funded node until patched.
3. Audit before you trust. Query the SQLite (or Postgres, if configured) database for:
   • Outbound payments in apipayments you do not recognize — especially clustered bursts or amounts just under round thresholds
   • Newly created wallets/accounts in the days before shutdown, particularly any that made outbound payments immediately after creation
   • Access logs showing POSTs to /api/v1/account, /api/v1/payments, and withdraw-extension endpoints from unfamiliar IPs
4. Monitor the official channels for the patch releases. Watch the LNbits GitHub repository (github.com/lnbits/lnbits) releases page and the project's official communication channels. Apply all pending security fixes — the project stated multiple fixes are coming, so a single release may not close every issue.
5. Harden before redeployment:
   • Restrict account creation (disable open registration where possible; LNbits supports admin-only wallet creation via the User Manager extension and environment configuration such as LNBITS_ALLOW_NEW_ACCOUNTS=false-style controls in recent versions — verify against current docs)
   • Put LNbits behind authenticated access (VPN, mTLS reverse proxy, or IP allowlisting) rather than exposing it directly to the internet
   • Set funding-wallet limits so the LNbits server's custodial balance is capped at operational minimums — never let the app hold more than you can afford to lose
   • Enable and ship application logs to a SIEM with alerting on withdrawal bursts
6. Assume compromise if you find theft. Rotate the Lightning node's macaroons/admin keys, review the node itself for unauthorized channels or payouts, and treat any host that ran an exposed, exploited LNbits instance as requiring full IR scoping.
7. If funds were stolen, document transaction IDs and destination node pubkeys from apipayments records — Lightning payments are traceable to the destination node, which matters for law-enforcement reporting and potential exchange freezes.

Bottom Line

When a project tells its entire user base to power down, believe them. LNbits operators are running internet-facing custodial wallet infrastructure, often with no monitoring and real Bitcoin at stake. The reported attack — new accounts draining server funds through the application's own payment rails — is exactly the kind of threat that produces no traditional malware artifacts. Your defenses are: take the service offline, secure the underlying funds, audit the transaction ledger, and do not redeploy until the maintainers ship the full set of fixes. Anything less is leaving the vault door open because the lock replacement is still in the mail.

Related Resources

Security Arsenal Healthcare Cybersecurity AlertMonitor Platform Book a SOC Assessment healthcare Intel Hub