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

Avoid oversized relayed failure messages

Public commit record

What the developer wrote

Authored by Matt Corallo

78/100 · Adequate
Avoid oversized relayed failure messages

A downstream peer could send a maximum-sized update_fail_htlc
without attribution data. Adding attribution data while relaying the
failure made the message exceed the Noise framing limit and panic
during encryption.

Drop the attribution data again when adding it would push the relayed
failure over the wire limit, while preserving attribution for packets
that fit. The message length is derived from serialized_length on the
message and on the attribution data itself rather than from hardcoded
field sizes, which also lets us replace a stale assertion on the
maximum failure data length. Add a regression test for relaying a
maximum-sized failure and correct the existing size test to include
the message type.

Reported by Project Loupe.

Co-Authored-By: Elias Rohrer <dev@tnull.de>
Co-Authored-By: HAL 9000
✓ Descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Mentions testing or verification
The short version

What changed, and why it matters

This patch fixes a crash bug in the Lightning Dev Kit's handling of HTLC failure messages. A downstream peer could send a maximally-sized failure message without attribution data. When the node added its own attribution data while relaying the failure, the resulting message became too large to fit within the Lightning Network's wire protocol limit, causing a panic during encryption. The fix drops the attribution data when adding it would exceed the limit, and adds a regression test.

Recommended action

Apply the patch and run the new regression tests. Nodes should upgrade promptly because the vulnerability is remotely triggerable by any downstream peer that can route a maximum-sized failure HTLC through the node, causing a panic and potential denial of service.

Security signals we found

01

Denial-of-service via remote-triggered panic in message encryption

02

Oversized message exceeding Noise/Lightning wire framing limit

03

Missing length validation before adding attribution data during relay

04

Stale hardcoded assertion replaced with dynamic wire-length check

05

Regression test added for maximum-sized relayed failure packet

Risk score

Why this scored 74/100

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