Settlement loop has no per-payment error isolation; a malformed zap request drops webhooks and zaps for other paylinks #1

New issue

Open

opened 2026-10-09 17:12:06 +00:00 by padreug · 0 comments

padreug commented

2026-10-09 17:12:06 +00:00

Owner

wait_for_paid_invoices (tasks.py:20-22) awaits on_invoice_paid inside while True with no try/except. send_zap (tasks.py:111-139) does json.loads(nostr) and assert pubkey on data that comes straight from the public LNURL callback's ?nostr= query parameter (views_lnurl.py:97-99, stored verbatim). Any payer of any zaps-enabled link can therefore make the shared listener raise after their invoice settles. lnbits core restarts the task after 5 s (catch_everything_and_restart), but the restart re-registers a fresh invoice queue, so the triggering payment's webhook and any payments queued behind it are lost — including plain (non-zap) webhook deliveries for unrelated tenants' links. The attacker controls timing and can repeat at will for the cost of a minimum-amount payment.

Fix direction: wrap the per-payment body in wait_for_paid_invoices in try/except (log and continue); make send_zap defensive (guard json.loads, early-return instead of assert); ideally reject malformed zap requests at the callback before creating the invoice (see sandbox lnurlp#3). Regression test: enqueue a payment with extra["nostr"] = "not json" followed by a valid one and assert the second still fires its webhook.

Found during reforge run #1 (sandbox lnurlp#4).

`wait_for_paid_invoices` (`tasks.py:20-22`) awaits `on_invoice_paid` inside `while True` with no try/except. `send_zap` (`tasks.py:111-139`) does `json.loads(nostr)` and `assert pubkey` on data that comes straight from the public LNURL callback's `?nostr=` query parameter (`views_lnurl.py:97-99`, stored verbatim). Any payer of any zaps-enabled link can therefore make the shared listener raise after their invoice settles. lnbits core restarts the task after 5 s (`catch_everything_and_restart`), but the restart re-registers a fresh invoice queue, so the triggering payment's webhook and any payments queued behind it are lost — including plain (non-zap) webhook deliveries for unrelated tenants' links. The attacker controls timing and can repeat at will for the cost of a minimum-amount payment. Fix direction: wrap the per-payment body in `wait_for_paid_invoices` in try/except (log and continue); make `send_zap` defensive (guard `json.loads`, early-return instead of `assert`); ideally reject malformed zap requests at the callback before creating the invoice (see sandbox lnurlp#3). Regression test: enqueue a payment with `extra["nostr"] = "not json"` followed by a valid one and assert the second still fires its webhook. Found during reforge run #1 (sandbox lnurlp#4).

padreug referenced this issue

2026-10-09 17:12:11 +00:00

webhook_url is unvalidated: server-side POST with attacker-chosen headers to any host (SSRF) #2

padreug referenced this issue

2026-10-09 17:12:18 +00:00

Nostr-transport create/update bypass the HTTP validation; fiat links created over the transport are served at 1/100 of the configured price #3

padreug referenced this issue

2026-10-09 17:12:23 +00:00

Lightning-address usernames are not unique: transport create/update skip the check and the schema has no constraint #4