LND HTLC First-Stage Sweep Failure Due to Wallet Budget Constraint

Impact

An anchor-channel peer could prevent a victim lnd node from recovering the value of outgoing HTLCs after a force close.

For anchor channels, the first-stage HTLC sweep transaction cannot be funded from the HTLC output itself; lnd must contribute internal-wallet inputs to pay for the sweep. To guard against fee-estimate uncertainty, lnd required at minimum twice the HTLC amount to be available in the internal wallet before attempting the sweep. Because lnd’s default configuration holds only the anchor reserve (up to 100,000 sats) in the internal wallet, any outgoing HTLC above approximately 50,000 sats could go unswept when a channel force-closes — the budget check fails and no sweep is attempted.

Two failure modes follow from this:

• For small HTLCs near the dust limit, the 2× budget guard has no useful protective effect. These HTLCs cannot be resolved on-chain at all, but lnd nevertheless left them in place across the commitment confirmation, causing the incoming channel to force-close as a cascading side effect.
• For larger HTLCs above the wallet-budget threshold, the sweep is skipped. An attacker who routes a large HTLC onto a victim’s channel and force-closes can wait for the HTLC to time out on-chain and claim its value via the timeout path.

The organic (non-adversarial) version of this bug was also observed in the wild: eventual sweeps at very high fee rates once wallet balance became available, and force closes of incoming channels as a downstream consequence.

Severity

Scored against the Lightning Labs severity taxonomy (4-dimension rubric):

Dimension	Score	Reasoning
Impact	Med	Per-victim fund loss when triggered adversarially. Excessive on-chain sweep fees and cascading incoming-channel force closes when triggered organically — observed in production.
Attack Vector	Med	Channel partner. The attacker must have an active channel with the victim to route HTLCs through it.
Exploitability	Med	The 100k-sat default anchor reserve makes a non-trivial fraction of lnd nodes vulnerable; an attacker running the exploit at scale will successfully hit a meaningful fraction of targets.
Virality	Low	Per-victim. Each attack requires specific HTLC routing on a dedicated channel; the technique does not propagate automatically.

Result: T1. Rule 2 (Impact = Med, base T1). No promotion (Vector ≠ High). No demotion (Exploitability ≠ Low; not both Vector and Virality are Low).

Patches

The two failure modes were addressed by separate changes, all landing in lnd v0.19.0-beta:

• lnd #9068 (“Cancel back outgoing dust HTLCs before commitment is confirmed”) cancels outgoing dust HTLCs upstream as soon as the local commitment transaction is broadcast, rather than waiting for confirmation. This eliminates the cascading incoming-channel force close for the dust case.
• lnd #9274 removes the hardcoded 2× budget requirement in the first-stage HTLC sweep and routes it through the configurable DeadlineHTLCRatio sweeper parameter (default 0.5). Under the new default, the sweep is self-funded from the HTLC output itself and no longer waits on internal-wallet top-up, closing the fund-loss path for larger HTLCs.
• lnd #9627 (“Sweep inputs even the budget cannot be covered”) is related hardening: the sweeper now attempts the sweep even when only part of the budget is covered by wallet inputs, rather than deferring until more UTXOs are available.

Users should update to v0.19.0-beta or later to be protected.

Disclosure timeline

• Identified internally by the Lightning Labs security team.
• Organic (non-adversarial) manifestations of the bug observed in the wild.
• Fix merged and released in lnd v0.19.0-beta.
• Public disclosure: 2026-08-11.