Skip to content

v0.2.7

v0.2.7 - Oct 1, 2026 - "LLMs vs Fuzzers"
@TheBlueMatt TheBlueMatt tagged this 02 Oct 00:00 
Bug Fixes
=========

 * Counterparties which both claim an HTLC and add a new HTLC in a single
   commitment update are no longer at risk of a spurious force-close (#5043).
 * When force-closing a channel which had an in-flight `ChannelMonitorUpdate`
   from a counterparty's state revocation blocked by another action (pending
   event, async `ChannelMonitorUpdate` on another channel, etc), we no longer
   forget to fail HTLCs which were removed in the revocation back (#5050).
 * When loading with a stale `ChannelManager` which had in-flight
   `ChannelMonitorUpdate`s blocked by another action (pending event, async
   `ChannelMonitorUpdate` on another channel, etc), we no longer fail an HTLC
   backwards which could still be claimed on-chain by out counterparty (#5046).
 * A race no longer exists when a channel which was force-closed by discovering
   a commitment transaction on-chain can lead to the force-closure of other
   channels or `Event::PaymentSent` missing until restart (#5030).
 * In rare cases where where a block is connected and immediately reorged out,
   it is no longer possible for a phantom `Balance` to remain, preventing
   `ChannelMonitor` archival (#5007).

Security
========

0.2.7 fixes a funds-theft vulnerability that can be exploited by a malicious
channel counterparty, a funds-theft vulnerability that can be exploited by an
LSPS2 client, and two denial-of-service vulnerabilities that can be exploited by
a malicious channel counterparty.
 * If a counterparty acknowledges a channel state update then reconnects and
   pretends not to have received it, they can no longer cause us to sign a
   conflicting commitment transaction at the same index, avoiding a potential
   avenue for funds-theft (#5057).
   Thanks to both Project Loupe and Nishant Bansal for independently reporting
   this issue.
 * An HTLC intercepted for the LSPS2 JIT flow can no longer lie about its amount
   and cause us to open a channel and forward more than the inbound HTLC
   provided us (#5042).
 * When accepting an inbound channel, our counterparty can no longer construct
   the funding transaction to cause `lightning-transaction-sync`'s
   Electrum-based sync to pull a substantial quantity of transactions (#4867).
Assets 2
Loading