The Lightning Development Kit (LDK), a library for building Bitcoin Lightning wallets and payment applications, has released security patches addressing a vulnerability that could allow a malicious channel peer to steal the value of a forwarded payment.
Released on October 1, versions 0.2.7 and 0.1.13 fix the reconnect flaw on their respective branches. The vulnerability was detailed by Bitcoin Optech in its October 9 newsletter.
How the Attack Works
The exploit occurs when a channel peer acknowledges an update, then reconnects and falsely claims it never received the acknowledgment. Before the patch, LDK could be manipulated into signing a conflicting commitment transaction—a transaction representing the channel's agreed state that can settle disputes on the Bitcoin blockchain.
The vulnerability arose because the newly signed transaction was not recorded by LDK's channel monitor, the component responsible for tracking the channel's on-chain claims. This gap could convert a forwarded payment into a loss for the intermediary node. A malicious sender could confirm the transaction on-chain and settle payment with the next recipient, then reclaim the incoming payment contract upon expiration despite the forwarding node knowing the secret required to claim payment.
The fix restricts transaction retransmission to periods when the peer's acknowledgment remains outstanding and force-closes the channel if the peer claims an already-acknowledged update was missed.
Additional LSPS2 Fix in v0.2.7
Version 0.2.7 also addresses a separate vulnerability in LSPS2 just-in-time payments, where a liquidity service opens a channel as part of handling a payment. An intercepted payment could misrepresent its amount, causing the service to forward more Bitcoin than the incoming payment supplied, requiring the service to cover the difference from its own funds.
Deployment Requirements
Since LDK is compiled and executed inside applications, developers must incorporate the patched library code into deployed software. For LSPS2 integrations, developers must also account for payment contracts queued by prior versions, which retain unvalidated amounts, in addition to updating the library itself.
