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

lnwire: reject onion message payloads with unknown even types

Public commit record

What the developer wrote

Authored by bitromortac

85/100 · Strong
lnwire: reject onion message payloads with unknown even types

BOLT 4 requires the final node to ignore an onion message whose
onionmsg_tlv contains an unknown even type, since even types are
"must understand". The TLV stream decoder does not enforce this on its
own: its parsed-type map collects unknown types of either parity, so an
even type such as 70 would otherwise be accepted as a final hop payload.

Reject any unknown even type during decode, regardless of its range. The
check runs before the final hop range skip so unknown even types below
type 64 are rejected as well.
✓ Specific, 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 commit fixes a standards-compliance bug in how LND decodes onion-routed messages in the Lightning Network. The relevant protocol rule (BOLT 4) says that if a message contains an unknown even-numbered data field, the receiver must reject the whole message because even fields are 'must understand.' LND was previously accepting such messages, which could let a peer make LND process or forward malformed/ambiguous onion messages. The patch now rejects any unknown even field during decoding, no matter what numeric range it falls in.

Recommended action

Treat this as a security-hardening fix and include it in the next maintenance release. Review whether any production paths currently catch or swallow decode errors from OnionMessagePayload.Decode, since callers now need to handle ErrUnknownEvenType by ignoring the message per BOLT 4. Consider an advisory if prior behavior could be abused to inject or relay invalid onion messages.

Security signals we found

01

Protocol compliance fix for BOLT 4 'must understand' even TLV types

02

Previously accepted malformed/ambiguous onion message payloads

03

Potential for protocol confusion or forwarding of invalid onion messages

04

New explicit error path introduced during decode

05

Test coverage added for both in-range and below-range unknown even types

Risk score

Why this scored 60/100

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