Core Lightning, software for operating Bitcoin Lightning payment nodes, is urging users to install v26.06.10 to address channel-security, payment-resolution, and remote-access flaws.
Maintainers also recommend reviewing the credentials used for remote commands, making access restrictions a separate task alongside the software upgrade.
The release notice recommends upgrading as soon as practical. Maintainers have temporarily withheld security-fix tests to slow the conversion of patches into working exploits and give operators more time to upgrade.
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.
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.
