Unpatched Bitcoin Lightning nodes face channel-draining bug

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.

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.