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

Validate HTTPS scheme in LSPS5 URL Readable deserialization

Public commit record

What the developer wrote

Authored by Vincenzo Palazzo

98/100 · Strong
Validate HTTPS scheme in LSPS5 URL Readable deserialization

The `Readable` implementations for `LSPSUrl` and `LSPS5WebhookUrl`
were bypassing URL validation, allowing non-HTTPS URLs (e.g., http://,
ftp://) to be deserialized from the wire protocol without rejection.
Only the serde `Deserialize` and `new()`/`parse()` paths were correctly
validating the HTTPS scheme.

Route `LSPSUrl::Readable` through `LSPSUrl::parse()` and add a length
check to `LSPS5WebhookUrl::Readable` so that wire-deserialized URLs
receive the same validation as JSON-deserialized ones.

Fixes #4559

Reported-by: Thomas Kilbride of Block Security
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode✓ Links an issue, advisory, or supporting reference✓ Names security-relevant behavior explicitly
The short version

What changed, and why it matters

This commit fixes a validation gap in the Lightning Dev Kit's LSPS5 (liquidity service) URL handling. When receiving a URL over the wire protocol, the code previously accepted any URL scheme, including insecure ones like http:// or ftp://. Now it enforces HTTPS-only URLs during deserialization, matching the validation already done for JSON input. It also adds a length check for webhook URLs.

Recommended action

Review whether any persisted or in-flight wire-serialized LSPS5 URLs with non-HTTPS schemes exist in deployed nodes, and consider whether additional transport-level enforcement is needed. The patch should be backported if supported release branches contain the vulnerable code.

Security signals we found

01

Bypass of existing HTTPS-only URL validation in wire deserialization path

02

Potential downgrade or redirection to insecure transport for LSPS5/webhook URLs

03

Inconsistent validation between serde/JSON and `Readable` deserialization paths

04

Addition of length limit enforcement for webhook URLs during deserialization

Risk score

Why this scored 64/100

Our methodology →
Potential impact 18/30
Exploitability 14/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.