LND update_fee Breach Fee-Burn Exploit

Impact

A channel initiator could cause a victim to recover little or nothing from a breach transaction by manipulating update_fee immediately before executing a fraudulent close.

The attack proceeds in five steps. Alice (the channel initiator) sends Bob an update_fee setting the fee rate high enough to burn the majority of the channel balance to transaction fees, completing a full commitment exchange. She then sends a second update_fee returning the fee rate to a normal level, completing another full exchange. At this point Alice’s node holds a revoked high-fee commitment. Alice performs a circular rebalance to empty the channel into another of her channels, then broadcasts the revoked high-fee commitment. Bob’s breach-remedy transaction successfully spends the breach output, but the fee rate in that commitment consumes nearly the entire channel balance — leaving Bob with at most the channel reserve.

Two variants exist. In the griefing variant Alice simply destroys the channel balance at a cost to herself of the reserve (approximately 1% of capacity). In the profit-seeking variant Alice colludes with a miner to capture the burned fees, netting approximately 97% of the channel balance at a reserve cost of 1%.

Severity

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

Dimension	Score	Reasoning
Impact	Med	Per-victim fund loss. The victim’s breach-remedy transaction is valid, but the channel balance has been burned to fees. Loss is bounded by the affected channel; each additional victim requires the attacker to fund a new channel (capital lock, on-chain cost), so damage is not disproportionate to attacker effort.
Attack Vector	Med	Channel partner only. The attacker must be the channel initiator in a funded channel with the victim.
Exploitability	High	The griefing variant is reliable against any channel partner. The profit-seeking variant requires miner collusion and is harder. The dominant variant drives the score.
Virality	Med	Replayable template. The same attack can be applied to any channel Alice has initiated, but each attempt requires a separately funded, capital-locked channel — so the marginal cost per victim is real, not near-zero, and virality is Med rather than High.

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 issue was fixed in lnd v0.18.3-beta by lnd #8824 (“multi: include commitment fees in dust calculation”, commit ac4ef28). On receiving an update_fee, the recipient now computes the proposed feerate’s total commitment-fee-plus-dust exposure on both commitments; if either would exceed the configurable MaxFeeExposure limit (default 500,000 sats), the update is rejected and the channel link fails. The same limit is applied on HTLC adds so that an attacker cannot bypass it by stuffing HTLCs to inflate commitment weight past the cap. Users should update to v0.18.3-beta or later to be protected.

Note: MaxFeeExposure is an absolute cap, not a fraction of channel capacity. On channels well above ~500,000 sats total balance the burn is bounded by the cap; on smaller channels a malicious initiator can still burn a significant fraction of the balance within it.

Disclosure timeline

• Reported to Lightning Labs by David Harding.
• Fix merged and released in lnd v0.18.3-beta.
• Public disclosure: 2026-08-11.

Credit

Reported by David Harding.