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

Invoice server: treat forwarded invreqs as OM forwards

Public commit record

What the developer wrote

Authored by Valentine Wallace

73/100 · Adequate
Invoice server: treat forwarded invreqs as OM forwards

Previously, when a static invoice server forwarded an invoice request to an
often-offline recipient, they would treat the outbound message like any other
outbound onion message initiated by their own node. That means they would
buffer the onion message internally in the onion messenger and generate a
ConnectionNeeded event if the next-hop node was offline.

Buffering the onion message in this case poses a DoS risk for the invoice
server node, since they do not control the quantity of invoice requests they
receive on behalf of often-offline recipients. Instead, we should treat these
forwarded invoice requests like any other onion message that needs to be
forwarded -- if the next-hop node is offline, either drop the message or
generate an OnionMessageIntercepted event for it (pushing the DoS management
onto the handler of the interception event).
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This change fixes a denial-of-service (DoS) risk in the Lightning Dev Kit's 'static invoice server' feature. Previously, when an invoice server forwarded a request to an often-offline recipient, it would internally buffer those messages and try to connect to the offline node, which could pile up and overwhelm the server. Now these forwarded requests are handled like normal onion message forwards: if the next hop is offline, the message is either dropped or handed off to the user via an interception event, pushing the DoS management burden onto the user instead of the server node.

Recommended action

Review and merge this patch if the static invoice server feature is used, as it closes a clear DoS vector. Operators using offline-peer interception should ensure their event handlers can manage `OnionMessageIntercepted` events for invoice requests, and wallet/docs should enforce that the `forward_invoice_request_path` introduction node is the server or a peer.

Security signals we found

01

DoS risk from unbounded internal buffering of forwarded invoice requests for offline recipients

02

Change from outbound-message buffering to forward-style handling (drop or intercept) for invoice requests

03

New MessageSendInstructions::ForwardedMessage variant to distinguish forwarded traffic from locally-originated traffic

04

Documentation update requiring invoice request path introduction node to be the server or its peer

05

Test update to ignore intercepted invoice requests when testing the static invoice flow

Risk score

Why this scored 62/100

Our methodology →
Potential impact 18/30
Exploitability 12/25
Stealth signal 10/15
Affected reach 10/15
Confidence 8/10
Evidence quality 4/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.