Document that LSPS5 services should double-check the destination
What the developer wrote
Authored by Matt Corallo
Document that LSPS5 services should double-check the destination
It would be easy to implement an LSPS5 service and forget that the
webhook calls are going out based on a URI and headers provided by
an untrusted client, so such implementations need to make sure to
check if the destination is some internal resource before sending.
Reported by Jordan Mecom of Block's Security Team
What changed, and why it matters
This commit only adds a documentation comment warning developers who build LSPS5 services that webhook URLs come from untrusted clients and could point to internal/private resources. It does not change any code behavior, so there is no direct vulnerability being fixed in the library itself. The risk is that a service built with this library might blindly call attacker-supplied URLs, leading to server-side request forgery (SSRF) or internal network probing. The commit is a safety reminder rather than a patch.
Treat this as a security-awareness note, not a completed fix. LSPS5 service implementers should add their own URL allowlisting/blocklisting, reject private/reserved IP ranges and localhost, and consider using a separate outbound proxy for webhook requests. The rust-lightning project may want to follow up with example code or helper utilities for safe webhook dispatch.
Security signals we found
Documentation-only change warning of untrusted user-supplied URL
Mentions risk of accessing internal or private resources (SSRF pattern)
Reported by an external security team (Block's Security Team)
No code-level mitigation added in the commit
Evidence from the diff
The diff adds three lines of Rust documentation to the LSPS5ServiceEvent::WebhookNotification event in lightning-liquidity/src/lsps5/event.rs. It warns that the url field is untrusted and that implementers should verify it does not target internal or private resources before issuing the HTTP request. No validation logic, URL parsing, or access controls are introduced. The underlying concern is SSRF: a malicious client registers a webhook URL such as http://localhost:8080/internal or a cloud metadata endpoint, and a naive service implementation forwards the notification there, potentially exposing internal services or credentials.
Changed components
lightning-liquidity/src/lsps5/event.rsLSPS5ServiceEvent::WebhookNotificationInspect captured patch +3 / −0
diff --git a/lightning-liquidity/src/lsps5/event.rs b/lightning-liquidity/src/lsps5/event.rs
index 30e3aea..f6ad6e1 100644
--- a/lightning-liquidity/src/lsps5/event.rs
+++ b/lightning-liquidity/src/lsps5/event.rs
@@ -56,6 +56,9 @@ pub enum LSPS5ServiceEvent {
///
/// This is the [`webhook URL`] provided by the client during registration.
///
+ /// Obviously as the URL provided here is untrusted you should check whether it would
+ /// access any internal or private resources and decline to send the request if it is.
+ ///
/// [`webhook URL`]: super::msgs::LSPS5WebhookUrl
url: LSPS5WebhookUrl,
/// Notification method with its parameters.
Why this scored 54/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.