The new version adds checks on a peer's transaction signatures during Bitcoin dual-funded channel opening and splicing, following the Lightning protocol's BOLT 2 specification, according to the tagged changelog.
A conditional Bitcoin payment contract, known as an HTLC, that had just been removed could be confused with a live one sharing its payment hash, amount and expiry. The node could then fail the live payment upstream even though its peer could still claim it.
Another fix rejects channel opens when a peer proposes a dust limit above 5,000 satoshis. The changelog says the previous behavior let a peer trim the node's balance into fees during a forced close. Dual-funded opens also reject a peer's dust limit when it exceeds the channel reserve.
Dual funding remains experimental, and maintainers discourage zero-confirmation channels with untrusted peers. The release also refuses a v2 zero-confirmation open unless the operator has configured acceptance for that peer.
Nodes that have run master cannot downgrade into the 26.06.x series because their database schema is newer.
GitHub displays a Nov. 4 release date for v26.06.10, while its tagged changelog dates the same version Nov. 5. The release follows the v26.06.9 security fixes and the Nov. 2 separate stored-trigger crash.
Core Lightning: patch the node, review remote access
Version 26.06.10 adds software checks. Maintainers also advise operators to bind and review issued commando credentials.
Install v26.06.10 and review commando runes: bind them to the intended node and replace credentials you cannot account for.
- Core Lightning maintainers strongly recommend that all users upgrade to v26.06.10 as soon as practical; the release contains security fixes and is available immediately. Core Lightning v26.06.10 release and rune guidance
- Version 26.06.10 adds verification of a peer's tx_signatures during dual-funded channel opening and splicing, in accordance with BOLT 2. Tagged v26.06.10 changelog: channel and remote-command fixes Core Lightning v26.06.10 release and rune guidance
- The new release prevents bypassing pname rune restrictions with duplicate or punctuation-variant parameter names, fixes a commando crash caused by command-ID reuse after a failed command, and rejects oversized runes rather than spending quadratic time decoding them. Tagged v26.06.10 changelog: channel and remote-command fixes
- Commando sends a directly connected peer a request to execute a command; the peer generally requires a rune authorizing that command. Official commando interface reference
- Maintainers recommend binding runes used over commando to the authorized application's node ID, blacklisting runes operators cannot account for with blacklistrune, and replacing them with more tightly restricted credentials. Core Lightning v26.06.10 release and rune guidance
- Dual funding remains experimental; the release discourages zero-confirmation channels with untrusted peers and refuses a v2 zero-confirmation open unless configured to accept one from that peer. Core Lightning v26.06.10 release and rune guidance Tagged v26.06.10 changelog: channel and remote-command fixes
Schematic of selected fixes and maintainer practices. It does not establish that every credential is appropriately restricted or that exploitation occurred.
Method: Schematic of two documented software surfaces, with selectable channel-check and remote-command details. Arrows show requests and maintenance steps, not bitcoin transfers, measured traffic or a live access test.
Review remote-command of Bitcoin credentials
Core Lightning's commando interface lets a directly connected peer request that a node execute a command. The peer generally needs a rune, an authorization credential permitting the command.
The update closes a way to bypass rune restrictions on parameter names using duplicate or punctuation-variant names. It also fixes a commando crash triggered by reusing a command ID after a failed command and rejects oversized runes that previously consumed excessive decoding work.
Maintainers recommend binding runes used over commando to the application's node ID through a id restriction. They also advise operators to blacklist runes they cannot account for using blacklistrune, then issue replacements with tighter restrictions.
cryptoslate.com
