# Disclosure: LND doesn't wait for enough confirmations when closing channels

**URL:** <https://delvingbitcoin.org/t/disclosure-lnd-doesnt-wait-for-enough-confirmations-when-closing-channels/2800>\
**Category:** Implementation\
**Tags:** lightning\
**Created:** [August 13, 2026, 3:06pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-doesnt-wait-for-enough-confirmations-when-closing-channels/2800 "2026-08-13T15:06:43Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![t-bast](https://delvingbitcoin.org/user_avatar/delvingbitcoin.org/t-bast/32/98_2.png) [@t-bast](https://delvingbitcoin.org/u/t-bast)\
**Post date:** [August 13, 2026, 3:06pm UTC](https://delvingbitcoin.org/t/disclosure-lnd-doesnt-wait-for-enough-confirmations-when-closing-channels/2800/1 "2026-08-13T15:06:43Z")

</div>

We’re disclosing a vulnerability in lnd, which was fixed version 20.0 (shipped in February 2026). Before this version, lnd would forget channels that were collaboratively closed immediately after their first on-chain confirmation, without waiting for more blocks to protect against reorgs. If a 1-block reorg happened, an attacker could then publish any revoked state for that channel and lnd would not publish penalty-transactions, resulting in a loss of funds up to the entire channel amount.

This can be reproduced on regtest with the following steps:

- open a large channel with an lnd node (e.g. 5 BTC)
- send payments through that node to move liquidity on the lnd side
- initiate a collaborative channel close
- generate 1 block, wait for the lnd node to detect the close
- invalidate that block with `bitcoin-cli invalidateblock `
- publish a revoked commitment transaction (e.g. the first commitment transaction where all the funds were on the attacker’s side)
- mine blocks: penalty transactions are never published and lnd lost funds

Timeline:

- I discovered the issue while testing `option_simple_close` between `eclair` and `lnd` in february 2025 (this wasn’t found using AI, which wasn’t cool at that time: crazy, right?)
- I identified the bug in lnd, which was here: [lnd/peer/brontide.go at 09a4d7e224a64499017c392abe2ccd7f5cc48d03 · lightningnetwork/lnd · GitHub](https://github.com/lightningnetwork/lnd/blob/09a4d7e224a64499017c392abe2ccd7f5cc48d03/peer/brontide.go#L3622)
- I notified laolu, who acknowledged the issue and fixed it in [https://github.com/lightningnetwork/lnd/pull/10331](https://github.com/lightningnetwork/lnd/pull/10331)
- the fix was included in lnd v20.0

Nobody was impacted as far as we know. The fix is simple: lightning nodes should always wait for many confirmations before considering a transaction confirmed and moving on. The BOLTs recommend 6 confirmations, and implementations should let node operators use higher values, but should not let node operators use values lower than 6.