Lightning Development Kit version 0.2.6, published on September 9, 2026, closes two security problems that could have affected applications built on Bitcoin’s Lightning Network.
One issue allowed a hostile channel partner to siphon a modest amount of value during a splice.
The other could leave a node unable to reload its saved channel data after a shutdown.
Maintainers of wallets and payment services that embed LDK need to pull the patched library into their builds.
LDK is not a standalone node.
It is a library that developers compile into mobile wallets, merchant stacks, and other Lightning products, pairing it with their own storage, networking, and blockchain-watch components.
Because the protocol logic lives inside those apps, a library update only helps once teams ship new binaries.
Splicing is the operation that adds or withdraws bitcoin from an already-open channel by spending the old funding output and creating a replacement.
Fees on that replacement transaction are split according to who contributed inputs and outputs and who started the process. A
calculation error in earlier 0.2.x code let a malicious peer inflate the fee assigned to the initiator.
The surplus did not vanish into the miner; it could be directed into the attacker’s output.
The official notes describe the exposure as small and only relevant when the local node starts the splice.
They do not publish a hard upper bound.
Version 0.2.6 corrects the allocation so excess fee can no longer be steered to the counterparty.
The second defect sat in payment handling inside ChannelManager, the component that tracks channels and in-flight transfers.
Lightning payments are identified by a payment hash.
If one hash was already used for a successfully forwarded contract, and the node then received and immediately refused a second, bogus contract with the same hash, persistence could write a ChannelManager snapshot that later failed deserialization.
Restarting a node means reading that snapshot back into memory.
A rejected snapshot means the process cannot come up cleanly.
Simply refusing the fake payment was not enough to avoid the corrupt write.
Erick Cestari is credited with reporting the issue.
The patch ensures that path can no longer leave the manager in an unloadable state.
The same release also tightens two related robustness cases.
Failed writes while serializing ChannelManager no longer emit false splice-failure and funding-discard events for splices that are still live.
Closing an unconfirmed, never-funded channel through ChainMonitor and crashing immediately afterward no longer makes the subsequent ChannelManager load fail.
The project states that it has not seen confirmed theft or exploited deployments.
The notes document the bugs and the repairs rather than a tally of lost coins.
That does not reduce the urgency for integrators.
Because LDK is compiled in, operators cannot “flip a switch” on a remote daemon; they must rebuild and roll out applications that depend on the older crate.
Splicing remains a relatively new capability in LDK’s 0.2 line, so fee-accounting edge cases matter as more wallets expose add-and-remove-funds flows.
The restart bug is broader: any node that processes payments and then stops can hit an unreadable state if the duplicate-hash sequence occurs first.
The fixes restore two basic guarantees—correct division of value when a channel is resized, and the ability to boot from disk after a stop. Teams should treat v0.2.6 as a required maintenance release, verify signatures, and ship the updated toolkit through their usual release process.