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

routerrpc: require encrypted blinded hop data

Public commit record

What the developer wrote

Authored by ziggie

68/100 · Adequate
routerrpc: require encrypted blinded hop data

SendToRouteV2 accepts caller-provided routes. It already required
recipient-encrypted data when a blinding point was present. However, it
copied a blinded total amount independently. This allowed a total-only
hop to enter the payment database even though LND did not classify it
as blinded.

Require encrypted data when either blinded field is supplied. Cover the
rejected combination, a valid blinded total and a regular hop.
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context
The short version

What changed, and why it matters

This commit tightens validation in LND's router RPC so that callers cannot supply a 'blinded total amount' for a payment hop unless they also provide the encrypted recipient data that marks the hop as blinded. It also restricts that total amount field to the final hop only. Previously, a route could be accepted with a blinded total amount on a regular hop, which could let inconsistent or partial blinded-payment data enter LND's payment database. The change is defensive and prevents a likely logic/state bug rather than a direct theft-of-funds vulnerability.

Recommended action

Treat as a security-hardening fix and include in release notes. Users running nodes that expose SendToRouteV2 to untrusted callers should upgrade. Review whether any other blinded-payment fields are accepted without their required companion fields.

Security signals we found

01

Input validation gap in caller-provided route deserialization

02

Blinded payment fields partially validated (blinding point required encrypted data, but total amount did not)

03

State/database consistency risk: partial blinded hop data could be persisted

04

BOLT 4 compliance fix: TotalAmtMsat restricted to final hop payload

05

Defensive hardening with unit-test coverage for rejected and accepted cases

Risk score

Why this scored 59/100

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