Merge pull request #11 from morehouse/lnd_excessive_failback_exploit_2

_posts: LND: Excessive Failback Exploit #2

Author: morehouse

_posts/2025-12-04-lnd-excessive-failback-exploit-2.md

@@ -0,0 +1,75 @@
+---
+layout: post
+title: "LND: Excessive Failback Exploit #2"
+description: "Discussion of a variant of the previously-disclosed excessive failback exploit in LND."
+modified: 2025-12-04
+tags: [lightning, security, theft, lnd]
+categories: [lightning]
+image:
+    feature: lnd_excessive_failback_exploit_2_header.png
+---
+
+A variant of the [excessive failback exploit](/lightning/lnd-excessive-failback-exploit/) disclosed earlier this year affects LND versions 0.18.5 and below, allowing attackers to steal node funds.
+Users should immediately upgrade to [LND 0.19.0](https://github.com/lightningnetwork/lnd/releases/tag/v0.19.0-beta) or later to protect their funds.
+
+## The Excessive Failback Bug Revisited
+
+As described in the previous [disclosure](/lightning/lnd-excessive-failback-exploit/), the original excessive failback bug existed in LND versions 0.17.5 and earlier.
+Essentially, when one of LND's channel peers force closed the channel, LND would mark any HTLCs missing from the confirmed commitment as "failed" in the database, even if the HTLC had actually succeeded with the *downstream* peer.
+If LND then restarted before the corresponding *upstream* HTLC was resolved, LND would incorrectly fail that HTLC with the upstream peer.
+Both the upstream and downstream peers would be able to claim the HTLC, and LND would be left with a loss.
+
+## The Variant Bug
+
+While a fix for the original excessive failback bug was included in LND 0.18.0, a minor variant of the bug remained when the channel was force closed using LND's commitment instead of the attacker's.
+In other words, the exact same attack was still possible if the attacker got the *victim* to force close the channel themselves.
+Unfortunately this is very easy to do; the attacker could simply send the victim an `error` message.
+
+## The Fix
+
+The excessive failback bug variant was [quietly fixed](https://github.com/lightningnetwork/lnd/commit/5a72d5258ff679071c4d7b687194e56ca163e02e) in the same way as the original bug, and the fix was included in the LND 0.19.0 release.
+
+## Discovery
+
+This variant was discovered shortly after the original disclosure, while I was [updating](https://github.com/lightning/bolts/pull/1233) BOLT 5 to prevent future excessive failback vulnerabilities.
+I realized there were actually *two* cases that needed to be updated in BOLT 5, but only one of the cases had been patched in LND.
+
+### Timeline
+
+- **2025-03-04:** Public disclosure of the [original](/lightning/lnd-excessive-failback-exploit/) excessive failback vulnerability.
+- **2025-03-04:** BOLT 5 update [drafted](https://github.com/lightning/bolts/pull/1233); variant discovered.
+- **2025-03-05:** Variant reported to the LND security mailing list.
+- **2025-03-20:** Fix [merged](https://github.com/lightningnetwork/lnd/pull/9602).
+- **2025-05-22:** LND 0.19.0 released containing the fix.
+- **2025-10-31:** Agreement to disclose publicly after LND 0.20.0 was released.
+- **2025-12-04:** Public disclosure.
+
+## Prevention
+
+In the previous disclosure post, I suggested that the excessive failback bug could have been prevented if the BOLT 5 specification had been clearer about how to handle HTLCs missing from confirmed commitment transactions.
+At the time, some Lightning maintainers were skeptical that a clearer specification would have helped.
+
+But this variant of the bug was only discovered *when I actually went and clarified BOLT 5 myself!*
+I think this is strong evidence that a clearer specification could have prevented both variants of the bug.
+
+## A Note on Collaboration
+
+As I noted in the previous excessive failback disclosure, it seems that at some point every Lightning implementation independently discovered and fixed bugs similar to the excessive failback bug in LND.
+Yet no one (including LND) thought to update the specification to help others avoid such bugs in the future.
+
+When I finally did update the specification, good things happened.
+This variant of the excessive failback bug was discovered and fixed in LND.
+But I also noticed that Eclair might have been vulnerable to this variant and reached out to Bastien Teinturier.
+While it turned out that Eclair was not vulnerable, the discussion with Bastien led to the accidental discovery of a different [serious vulnerability](/lightning/eclair-preimage-extraction-exploit/) in Eclair.
+
+This all happened from just a tiny bit of collaboration: a specification update for the common good and a short conversation with Bastien.
+In many ways, it is quite unfortunate that Lightning engineering talent is spread out over so many implementations.
+Everyone focuses on their own code first, and collaboration is secondary.
+Efforts are duplicated and lessons are learned multiple times.
+Imagine what we could accomplish with a little more cooperation.
+
+## Takeaways
+
+- Clear specifications benefit all Lightning implementations.
+- We should do more cross-implementation collaboration.
+- Users should keep their node software updated.