
Unpatched Bitcoin Lightning nodes face channel-draining bug
Core Lightning urges Bitcoin node operators to patch payment and channel security flaws in v26.06.10, which adds signature checks and remote-access fixes.
Core Lightning, software for operating Bitcoin Lightning payment nodes, is urging users to install v26.06.10 to address critical channel-security, payment-resolution, and remote-access flaws. The update comes as maintainers warn of vulnerabilities that could potentially drain payment channels if left unpatched.
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. These signature verification processes help prevent unauthorized channel operations that could compromise user funds.
Payment resolution fixes
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, potentially causing transaction failures and fund loss.
Another fix rejects channel opens when a peer proposes a dust limit above 5,000 satoshis. The changelog explains that the previous behavior allowed a peer to trim the node's balance into fees during a forced close. Dual-funded opens also now reject a peer's dust limit when it exceeds the channel reserve.
Remote access security
The release addresses multiple remote-command vulnerabilities, including 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.
Install v26.06.10 and review commando runes: bind them to the intended node and replace credentials you cannot account for.
Experimental features caution
Maintainers emphasize that dual funding remains experimental and discourage zero-confirmation channels with untrusted peers. The release now refuses a v2 zero-confirmation open unless the operator has specifically configured acceptance for that peer, adding an extra layer of protection against potentially risky connections.
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, following the v26.06.9 security fixes and the Nov. 2 separate stored-trigger crash.
Maintainers have temporarily withheld security-fix tests to slow the conversion of patches into working exploits and give operators more time to upgrade. They strongly recommend that all users upgrade to v26.06.10 as soon as practical to protect their Bitcoin Lightning nodes from potential attacks.