Lightning's LDK Patches a Splice Fee Bug and a Restart Failure

The Lightning Development Kit shipped version 0.2.6 on 9 September with two security fixes in it. One stops a hostile peer inflating the fee a node pays when it adds funds to a channel that is already open. The other stops a node reaching a state it cannot read back when it restarts. Neither has been exploited, on everything published so far. LDK is a library and not a running daemon, so the fixes reach users only when the wallets built on it rebuild and ship.
What the splice fix stops
Splicing is the act of adding or removing funds from a Lightning channel without closing it, and the on-chain fee for that transaction is shared between the two sides. The release notes describe the flaw in a single line.
"A malicious splice peer can no longer cause us to somewhat over-allocate fee when we contribute to a splice, with the over-allocation going to their output," the changelog said.
The over-allocated amount lands with the peer who caused it. The notes file the change under pull request #4905 and put no number on what a peer could have taken.
A duplicate hash and a node that would not start
The second fix is the stranger of the two. Payments on Lightning are identified by a hash, and a node forwards a payment contract that carries one. Where bogus contracts sharing a hash with one that had already been forwarded successfully were then rejected, the ChannelManager, the component holding a node's channel and payment state, could end up in a condition that fails to deserialize. A node in that condition does not come back cleanly. That fix is pull request #4982, and the notes credit Erick Cestari with reporting it.
Critical is CryptoSlate's word, not LDK's
The release notes call the pair a denial-of-service vulnerability and a fee-inflation issue. CryptoSlate, writing on Sunday, headlined them as critical bugs that exposed nodes to fund theft, and described the splice flaw as letting a peer divert small amounts from nodes that initiate splices. Those are not the same claim. We went to the changelog at the v0.2.6 tag to check, and the line quoted above is the whole of what the project says about severity. Neither account acknowledges the other.
Two ordinary bugs went out in the same release, under the title "The More You Dig". Stream write failures while serializing a ChannelManager no longer throw spurious splice-negotiation-failure events, and closing an unfunded channel followed immediately by a crash no longer breaks startup.
Nobody can count who has upgraded
Core Lightning, a separate implementation of the same protocol, held its own bug details for 14 days in late August, after an AI-assisted sweep that returned 4,962 findings across 390 Bitcoin repositories. Nothing published ties that episode to this one, and the two projects share no code. What they do not share is how a fix travels. Core Lightning operators run a daemon and can update it themselves; LDK is compiled into somebody else's application, and its users update when that application does.
Lightspark, Alby Hub, Cash App and Lexe are the four projects LDK's own site names as building on it. None has said publicly whether it has taken 0.2.6, and no register would show it either way. That is the part left open. A patched library sits in a repository until the next app release carries it out, and the people whose channels it protects never see the version number.
Read also: Bitcoin Core 31.1 Fixes a Disk-Thrashing Chainstate Bug