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

Add LSPS5 DOS protections.

Public commit record

What the developer wrote

Authored by Martin Saposnic

80/100 · Strong
Add LSPS5 DOS protections.

When handling an incoming LSPS5 request, the manager will check
if the counterparty is 'engaged' in some way before responding.
`Engaged` meaning = active channel | LSPS2 active operation | LSPS1 active operation.

Logic: `If not engaged then reject request;`

A single test is added only checking for the active channel condition,
because it's not super easy to get LSPS1-2 on the correct state to check this (yet).
Other tangential work is happening that will make this easier and more tests will come in the near future
✓ Descriptive subject✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Mentions testing or verification
The short version

What changed, and why it matters

This commit adds a new access-control rule to the LSPS5 (webhook) service in rust-lightning. Before accepting a state-allocating LSPS5 request such as 'set webhook', the service now requires proof that the requesting peer is already 'engaged' with the LSP: either an open Lightning channel, an active LSPS2 JIT-channel flow, or an active LSPS1 order flow. If none of those exist, the request is rejected with a new 'NoPriorActivity' protocol error. The change is framed by the authors as a DoS protection, because registering webhooks consumes server-side state and previously any peer could do it without prior relationship.

Recommended action

Treat as a hardening/DoS-mitigation change rather than a critical vulnerability fix. Review whether the engagement criteria are sufficient and correctly synchronized with channel/flow lifecycle state. Consider adding tests for the LSPS1 engagement path once the necessary test infrastructure is available, as the commit notes that only the active-channel condition is currently tested.

Security signals we found

01

New access-control gate for state-allocating LSPS5 requests

02

New protocol error code LSPS5_NO_PRIOR_ACTIVITY_ERROR_CODE (1003) and enum variant NoPriorActivityError

03

Addition of has_active_requests() on LSPS1/LSPS2 service handlers to detect active peer flows

04

Manager-level check combining open channel + LSPS2 active + LSPS1 active before calling LSPS5 handler

05

Error response uses IgnoreAndLog, which is consistent with benign policy rejection rather than a fatal protocol violation

06

Tests updated to establish prior engagement; new DoS protection test added

Risk score

Why this scored 52/100

Our methodology →
Potential impact 12/30
Exploitability 10/25
Stealth signal 8/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.