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

Throttle LSPS5 lifecycle cooldown resets

Public commit record

What the developer wrote

Authored by Elias Rohrer

80/100 · Strong
Throttle LSPS5 lifecycle cooldown resets

LSPS5 resets notification cooldowns when a peer reconnects so clients
can receive prompt wake-ups after coming online. A peer can otherwise
churn connections to clear the webhook cooldown repeatedly, turning the
LSP into an amplification source for registered notification URLs.

Rate-limit how often peer lifecycle events may clear notification
cooldowns while keeping the first reset immediate. Also make
LSPSDateTime elapsed-time calculation directional so backwards clock
movement does not make future timestamps look expired.

Co-Authored-By: HAL 9000

This finding was discovered by Project Loupe
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This patch fixes a denial-of-service/amplification weakness in the LSPS5 webhook service of rust-lightning. Previously, every time a peer connected or disconnected, the LSP would immediately clear the one-minute 'cooldown' that prevents repeated webhook notifications. A malicious or misbehaving peer could repeatedly connect and disconnect to force the LSP to send many webhook requests to registered URLs, effectively using the LSP as an amplifier against third-party servers. The patch now allows only one cooldown reset every 10 seconds per peer. It also fixes a related time-calculation bug so that a clock moving backward does not incorrectly make future timestamps look expired.

Recommended action

Treat as a security fix. Review whether deployed LSP nodes running LSPS5 need this patch, and consider whether the 10-second reset throttle is appropriate for expected peer churn rates. No CVE or advisory is supplied in the materials.

Security signals we found

01

Rate-limit added to peer lifecycle cooldown reset to prevent amplification

02

LSPSDateTime::duration_since made directional to avoid backward-clock misbehavior

03

Commit message explicitly describes security-relevant abuse scenario (peer churn turning LSP into amplification source)

04

Tests added to verify throttling and directional duration behavior

Risk score

Why this scored 68/100

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