# Disclosure: LND Excessive Failback Exploit **URL:** \ **Category:** Implementation\ **Tags:** lightning, announcement\ **Created:** [March 4, 2025, 3:58pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493 "2025-03-04T15:58:58Z")\ **Posts on this page:** 1\ **Showing post:** 8
**Author:** ![ariard](https://delvingbitcoin.org/letter_avatar_proxy/v4/letter/a/c67d28/32.png) [@ariard](https://delvingbitcoin.org/u/ariard)\ **Post date:** [March 30, 2025, 8:35pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493/8 "2025-03-30T20:35:16Z")
> This is hard to follow because it looks like you’re confusing `downstream` and `upstream` in several of your paragraphs…I think I got the gist of it though, but I don’t see how it applies to the change you’re referring to. We do no use downstream or upstream as terminology in BOLT5, so lightning channels are always both directionals at all time, unless you unset the chan for forwarding (e.g with `announce_for_forwarding=false` in rust-lightning). For the matter of present analysis, the fact that you can have `offerered` and `received` HTLCs pending is an element to consider (e.g a node can inflate the feerate cost of a commitment tx). However, in the present example, yes all the HTLCs are supposed to flow from Mallory to Mallet, so I’m correcting that in the initial post. > [@t-bast](#): > > The BOLTs change only says that the preimage must be relayed upstream as soon as it’s obtained downstream. At that point we only specify that nodes should correctly extract preimages from downstream and send `update_fulfill_htlc` upstream. This doesn’t change the requirements of whether the node should force-close upstream (if its `update_fulfill_htlc` is not acked) or not. Note as I was pointing out to Morehouse above before the fixes, the problem is antecedent to the BOLTs’s change. The fixes by indicating that the “_MUST fulfill the corresponding incoming HTLC_” as soon as the preimage is known, without waiting for a final `revoke_and_ack` of the peer or a local or remote commitment transaction that has reached reasonable depth in the chain. --- _[View the full topic](https://delvingbitcoin.org/t/disclosure-lnd-excessive-failback-exploit/1493)._