LND Invoice Marked Settled After HTLC Cancelled by Interceptor

Impact

A Lightning Terminal node running tapd with the invoice HTLC interceptor enabled, even with no asset channels open, could record an invoice as settled while the HTLC that paid it had been cancelled back to the sender on the wire. The node’s own accounting then disagreed with what actually happened: the invoice showed as paid, but no funds moved.

Two defects combined:

• tapd’s invoice acceptor treated any HTLC carrying custom wire records as an asset HTLC. Senders setting the experimental endorsement TLV, which some implementations did by default, triggered this on ordinary BTC payments. The acceptor then applied its strict-forwarding rule and instructed lnd to cancel the HTLC set.
• lnd’s handling of that cancellation cancelled the HTLC on the wire but still updated the invoice in the database as settled.

The lnd defect is not specific to tapd. Any client of the HtlcModifier RPC, introduced in lnd 0.18.4-beta, that cancelled an HTLC set would have produced the same mismatch between the database and the wire; tapd’s acceptor was the trigger observed in the field. Operators running any other client of the HtlcModifier RPC against lnd 0.18.4 or 0.18.5 are in scope.

An operator, or software reading the invoice state, could be led to release goods or credit against a payment that never completed. The sender’s funds were not at risk; the HTLC was correctly returned.

Severity

Scored against the Lightning Labs severity taxonomy:

Dimension	Score	Reasoning
Impact	Med	Reporting-integrity defect, scored Med rather than the default Low because the false settled state is itself what causes the operator to release value against a payment that never completed. Per-victim; each invoice is a separate loss.
Attack Vector	High	Network. Any payment sender on the network; no channel or peer relationship with the victim is required.
Exploitability	Med	The victim had to run litd with tapd’s acceptor enabled, a common default at the time, and the sender’s implementation had to set the triggering TLV.
Virality	Low	Per-victim per-invoice.

Result: T1. Rule 2 (Impact = Med, base T1); no promotion (Exploitability is Med, and promotion needs all three of Attack Vector, Exploitability and Virality at High); no demotion (Exploitability is not Low and Attack Vector is not Low).

Patches

tapd side, released in v0.5.1: tapd#1322, tapd#1330, tapd#1334, which correctly identify asset HTLCs rather than treating any custom record as one.

lnd side, released in v0.19.0-beta: lnd#9454, which fails the HTLC set consistently when the interceptor cancels, so the database state matches the wire.

Both fixes are needed for full protection. For Lightning Terminal, which bundles both daemons, the mapping is:

Lightning Terminal	tapd	lnd	state
v0.14.0-alpha	v0.5.0	v0.18.4-beta	both defects present
v0.14.1-alpha	v0.5.1	v0.18.5-beta	trigger fixed; lnd defect present
v0.15.0-alpha	v0.6.0	v0.19.1-beta	both fixed

The fix_date on this advisory is the tapd release of 2025-02-12, which closed the observed trigger for every Lightning Terminal user; the underlying lnd defect remained reachable by other interceptor clients until lnd 0.19.0-beta on 2025-05-22. Operators unable to update could mitigate by running litd with --taproot-assets-mode=disable when no asset channels are in use.

Disclosure timeline

• Identified 2025-01-27 from a field report of an invoice showing settled after the HTLC was cancelled.
• tapd fix released in v0.5.1 on 2025-02-12; lnd fix released in v0.19.0-beta on 2025-05-22.
• Public disclosure: 2026-09-21.