Community Trust ScoreVerified
Core Lightning maintainers released version 26.06.10 on November 4 to address channel-security, payment-resolution, and remote-access flaws in the Bitcoin Lightning node software. The update includes a fix for a channel-draining bug that allowed peers to trim node balances into fees during forced closes, along with new signature checks for dual-funded channel operations.
Channel Security and Payment Fixes
The release adds verification of a peer’s transaction signatures during Bitcoin dual-funded channel opening and splicing, in accordance with the Lightning protocol’s BOLT 2 specification. This change ensures that nodes correctly validate peer actions during these experimental processes.
A critical fix addresses an issue where a removed Hashed Time-Locked Contract (HTLC) could be confused with a live one sharing the same payment hash, amount, and expiry. In the previous version, this confusion could cause the node to fail a live payment upstream, even though the peer was still able to claim the funds. The new version resolves this payment-resolution error.
Maintainers also introduced a limit on channel dust thresholds. The software now rejects channel opens when a peer proposes a dust limit above 5,000 satoshis. The changelog notes that the previous behavior allowed a malicious or faulty peer to trim the node’s balance into fees during a forced close. For dual-funded opens, the software also rejects a peer’s dust limit if it exceeds the channel reserve.
Dual funding remains an experimental feature, and maintainers continue to discourage the use of zero-confirmation channels with untrusted peers. The release refuses v2 zero-confirmation opens unless the operator has explicitly configured acceptance for that specific peer. Additionally, nodes that have run the master branch cannot downgrade to the 26.06.x series because their database schema is newer.
Remote Command and Credential Management
The update also addresses flaws in the commando interface, which allows directly connected peers to request that a node execute specific commands. These requests generally require a rune, an authorization credential that permits the command. The new version prevents bypassing pname rune restrictions using duplicate or punctuation-variant parameter names.
Other fixes include resolving a commando crash caused by command-ID reuse after a failed command and rejecting oversized runes to prevent excessive decoding work. Maintainers recommend that operators bind runes used over commando to the authorized application’s node ID. They also advise blacklisting runes that operators cannot account for using the blacklistrune function and replacing them with more tightly restricted credentials.
Maintainers have temporarily withheld security-fix tests to slow the conversion of patches into working exploits, giving operators more time to upgrade. The release follows the v26.06.9 security fixes and a separate stored-trigger crash reported on November 2. GitHub displays a November 4 release date for v26.06.10, while the tagged changelog dates the same version November 5.
Frequently Asked Questions
What is the main security fix in Core Lightning v26.06.10?
The release fixes a channel-draining bug where a peer could trim the node’s balance into fees during a forced close by proposing a dust limit above 5,000 satoshis.
How should operators manage commando credentials after upgrading?
Operators should bind runes to the intended node ID, blacklist any runes they cannot account for, and replace unaccounted-for credentials with more tightly restricted ones.
