Key Highlights:
- Core Lightning has released version 26.06.10, delivering essential security fixes for Lightning channel operations and remote command execution.
- Key protocol updates resolve critical bugs involving HTLC race conditions, excessive dust limits during channel opens, and signature validation across dual-funding and splicing workflows.
- Maintainers urge node operators to immediately audit, blacklist, and restrict
commandorunes to protect remote access surfaces from parameter bypasses and related vulnerabilities.
Core Lightning v26.06.10 Delivers Critical Protocol and Security Patches
Maintainers of Core Lightning (CLN) have released version 26.06.10, rolling out an array of security enhancements, channel-management fixes, and access-control mitigations. The releaseādated November 4 on GitHub and November 5 in the tagged changelogāarrives shortly after the v26.06.9 security updates and addresses a separate stored-trigger crash reported on November 2. The development team strongly advises node runners to upgrade as soon as practical to secure their infrastructure against channel manipulation and remote-command edge cases.
A central focus of the v26.06.10 update is ensuring stricter adherence to the Lightning Network’s BOLT 2 specification. The software now adds explicit checks verifying peer transaction signatures (tx_signatures) during both dual-funded channel openings and splicing procedures. Additionally, developers resolved a dangerous race condition in Hash Time-Locked Contract (HTLC) tracking. Previously, a newly removed conditional payment contract could be conflated with an active HTLC that shared an identical payment hash, amount, and expiry time. This flaw created a scenario where the node might erroneously fail the active payment upstream, even while the peer remained capable of claiming the funds downstream.
Channel Management Protections and Dual-Funding Guardrails
The release bolsters protections against unfair fee-trimming tactics during channel closure disputes. Under the revised rules, Core Lightning rejects channel open attempts whenever a counterparty proposes a dust limit exceeding 5,000 satoshis. According to the release documentation, earlier versions permitted a peer to force a closure while effectively absorbing the local node’s balance into mining fees via an inflated dust threshold. For dual-funded channel negotiations, the software also automatically rejects any proposed dust limit that exceeds the agreed channel reserve.
Because dual funding remains an experimental feature across the Lightning Network ecosystem, project maintainers actively discourage establishing zero-confirmation (zero-conf) channels with untrusted counterparties. To reinforce this safeguard, version 26.06.10 outright rejects version 2 (v2) zero-confirmation channel open requests unless the node operator has explicitly configured the node to accept such arrangements from that specific peer. Operators should also be aware that nodes running the unstable master branch cannot roll back to the 26.06.x release line due to forward-incompatible database schema revisions.
Trump Media Transfers $342 Million in Bitcoin, Raising Speculation of a Potential Sale
Fortifying Commando and Rune Authorization Credentials
Beyond channel logic, Core Lightning v26.06.10 targets the node’s remote management surface by hardening commando, an interface enabling connected peers to execute node commands through tokenized credentials known as “runes.” The update closes an authorization loophole where users could bypass parameter name (pname) rune restrictions through duplicate parameter names or slight punctuation variations. It also resolves a commando daemon crash caused by command-ID reuse after a failed operation and enforces size limits on runes to eliminate quadratic CPU consumption during decoding.
Alongside the software patch, maintainers issued targeted operational guidance for managing remote credentials. Operators are advised to audit all outstanding runes, using the blacklistrune command to revoke unaccounted-for or overly broad tokens. Maintainers recommend reissuing runes with strict id constraints to bind each credential directly to the specific node ID of the authorized client application.
Why This Matters
As the Lightning Network scales its routing liquidity and introduces complex primitives like splicing and dual-funded channels, safeguarding edge-case interactions between peers becomes paramount. Flaws involving HTLC resolution or manipulated channel-opening parameters risk draining funds or causing payment failures across the network graph. By closing parameter bypass vectors in commando and curtailing potential fee-siphoning vectors during unilateral channel closes, Core Lightning v26.06.10 reinforces operational resilience for both high-volume routing nodes and remote-controlled Lightning backends.
Frequently Asked Questions
Why is upgrading to Core Lightning v26.06.10 recommended?
The release patches potential fund-loss scenariosāsuch as improper upstream HTLC cancellations and dust-limit balance trimming on forced closesāwhile preventing remote crashes and credential bypasses within the commando interface.
Can node operators downgrade to v26.06.10 from the master branch?
No. Nodes that have run the master development branch cannot downgrade to the 26.06.x series because the database schema in master is newer and incompatible with earlier point releases.
What steps should operators take to secure their commando runes?
Operators should audit all active credentials, revoke any unverified tokens using the blacklistrune tool, and reissue fresh credentials that strictly bind authorization to the intended client’s node ID using id restrictions.
