AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Low 28 Bitcoin

lnurl: implement LNURL-withdraw

Public commit record

What the developer wrote

Authored by f321x

58/100 · Thin
lnurl: implement LNURL-withdraw

adds handling of lnurl-withdraw payment identifiers which allow users to
withdraw bitcoin from a service by scanning a qr code or pasting the
lnurl-w code as "sending" address.
✓ Descriptive subject✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit adds a new feature to Electrum that lets users withdraw bitcoin from a service by scanning or pasting an LNURL-withdraw code. It is a feature addition, not a fix for a known vulnerability. The code does include some safety checks, such as only allowing HTTPS or .onion callback URLs and warning users not to trust error messages from the LNURL server. However, because this is brand-new code handling real money withdrawals and interacting with external services, it introduces new attack surface. There is no direct evidence in the commit of an exploitable bug, but the change is security-relevant by nature.

Recommended action

Treat this as a security-relevant feature addition requiring focused review. Audit the LNURL3 parsing and callback flow for: missing or insufficient validation of k1, defaultDescription, and amount fields; correct handling of network errors and timeouts; whether the BOLT11 invoice creation uses appropriate expiry and routing hints; and that the GUI cannot be tricked into sending an invoice to a malicious callback. Consider adding tests for malformed responses, large amounts, and callback failure modes. No immediate emergency action is warranted based solely on the diff.

Security signals we found

01

New network-facing feature that creates BOLT11 invoices and sends them to arbitrary (but URL-validated) LNURL service callbacks

02

Callback URL scheme validation restricts to https:// or .onion to reduce MITM/phishing risk

03

LNURLError messages are explicitly distrusted to mitigate social-engineering via malicious server error text

04

Amount bounds validated against channel inbound liquidity before initiating withdrawal

05

Payment identifier state machine extended with LNURLW_FINALIZE to separate withdraw flow from pay flow

06

Minor logging fix in lnworker.py: operator precedence corrected for satoshi amount display

Risk score

Why this scored 28/100

Our methodology →
Potential impact 4/30
Exploitability 5/25
Stealth signal 4/15
Affected reach 6/15
Confidence 6/10
Evidence quality 3/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.