LND: Excessive Failback Exploit #2

LND: Excessive Failback Exploit #2

A variant of the 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 or later to protect their funds.

The Excessive Failback Bug Revisited

As described in the previous disclosure, 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 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 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 excessive failback vulnerability.
  • 2025-03-04: BOLT 5 update drafted; variant discovered.
  • 2025-03-05: Variant reported to the LND security mailing list.
  • 2025-03-20: Fix merged.
  • 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 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.

Matt Morehouse

Matt Morehouse
Software engineer working to improve the security and stability of the Bitcoin Lightning Network.

LND: Replacement Stalling Attack

Discussion of weaknesses in LND's sweeper system that can be exploited to steal funds. Continue reading

LND: Infinite Inbox DoS

Published on December 04, 2025

Eclair: Preimage Extraction Exploit

Published on September 23, 2025