Lightning Development Kit

Lightning Development Kit maintainers shipped security releases that close a flaw letting a dishonest channel partner steal a forwarded Bitcoin payment by lying after a reconnection. Any wallet or payment app built on an unpatched copy of the toolkit remains exposed until its developers rebuild and redeploy it, which matters because LDK underpins custodial and non-custodial Lightning products that institutions use for instant Bitcoin settlement.

• LDK’s v0.2.7 and v0.1.13 security releases, dated Oct. 1, fix a reconnect flaw across both the 0.2 and 0.1 code branches.
• Before the fix, a peer could falsely claim it never received an acknowledged update, tricking LDK into signing an untracked commitment transaction.
• Version 0.2.7 separately fixes an LSPS2 just-in-time channel bug that could have forced a liquidity service to cover an attacker’s shortfall from its own funds.

• Oct. 1 date both patched branches, v0.2.7 and v0.1.13, were released
• Sept. 13 prior LDK v0.2.6 disclosure

Lightning Development Kit maintainers released v0.2.7 and v0.1.13 on Oct. 1, 2026, patching a flaw that let a malicious channel partner steal the value of a forwarded Bitcoin payment by lying after reconnecting, according to the Oct. 9 newsletter from Bitcoin Optech. LDK is a software toolkit, not a standalone program, that developers compile directly into wallets and payment apps to run Bitcoin’s Lightning Network, the layer-two protocol used for fast, low-fee transactions off Bitcoin’s base chain.

Because LDK ships as embedded code rather than a shared daemon, the fix only protects applications whose developers actually rebuild and redeploy it. CryptoSlate detailed that distribution problem in its report on the vulnerability.

A Reconnect Lie Let Peers Sign a Commitment Transaction LDK Never Tracked

The attack begins with a channel peer acknowledging a payment update, then reconnecting and falsely claiming it never received that acknowledgment. Before the fix, LDK could respond by signing a conflicting commitment transaction, the record of a channel’s agreed state that can be broadcast to settle it on Bitcoin’s blockchain. The flaw, tracked in PR 5057, meant that newly signed transaction never got recorded by LDK’s channel monitor, the component responsible for tracking a channel’s on-chain claims.

That gap turned a forwarded payment into a potential loss for the operator caught in the middle. A malicious sender could confirm the false transaction on-chain, let the payment settle with the downstream recipient, and then reclaim the incoming payment contract once it expired, even though the forwarding node knew the secret needed to claim it.

The forwarding node would have paid out downstream without recovering the matching incoming funds. The fix now permits retransmission only while an acknowledgment remains genuinely outstanding and force-closes the channel if a peer claims a confirmed update was missed.

Version 0.2.7 Also Closes an Overpayment Gap for Liquidity Providers

Alongside the reconnect fix, v0.2.7 addresses a separate issue in LSPS2, a specification that lets a liquidity service provider open a channel on the fly when it receives a payment larger than a user’s existing capacity, a mechanism commonly used for instant onboarding in mobile and custodial Lightning wallets. An intercepted payment could misrepresent its own amount, pushing the service to open a channel and forward more Bitcoin than it actually received. The provider would then have to cover the shortfall from its own balance, and PR 5042 adds the missing amount check.

The v0.1.13 release notes list only the shared reconnect fix, not the LSPS2 fix, leaving apps on that branch exposed to the liquidity-service issue if they use the feature. The PR 5042 notes also flag that payment contracts queued under a prior version still carry unvalidated amounts, so teams must account for those pending contracts separately from simply upgrading the library.

LDK’s Embedded Design Means Every App Has to Rebuild Itself

LDK’s own architecture documentation explains why patching is uneven across the ecosystem: the SDK is compiled and executed inside each application rather than run as a shared daemon, leaving developers to choose their own storage, wallet and blockchain-monitoring code. That environment-agnostic design is what let CryptoSlate’s prior v0.2.6 report on Sept. 13, 2026 describe a separate set of splice-fee and state-loading bugs just weeks before this disclosure.