NewsCryptoCore Lightning Releases v26.06.10 With Security Fixes, Urges Bitcoin Node Operators to Rotate Runes

Core Lightning Releases v26.06.10 With Security Fixes, Urges Bitcoin Node Operators to Rotate Runes

Author: Coincentral·

Key Takeaways

  • •Core Lightning version 26.06.10 ships security fixes, and its maintainers are asking all users to upgrade as soon as practical, alongside a separate review of credentials used for remote commands.
  • •The update closes a way to bypass rune limits on parameter names via duplicate or punctuation-variant names, fixes a commando crash caused by reusing a command ID, and now rejects oversized runes outright.
  • •Operators are advised to bind each commando rune to the node ID of its app, blacklist any runes they cannot account for, and issue new runes with tighter restrictions.
  • •The release adds transaction signature checks during dual-funded channel opening and splicing, refuses dust limits above 5,000 satoshis in channel opens, and blocks v2 zero-confirmation opens unless explicitly permitted for that peer.
  • •This is the third consecutive point release published without an embargo period, with security tests withheld to make converting the fixes into working exploits harder and give users more time to upgrade.
Core Lightning Releases v26.06.10 With Security Fixes, Urges Bitcoin Node Operators to Rotate Runes

Core Lightning, one of the major software implementations used to run Bitcoin Lightning payment nodes, has released version 26.06.10 with a new set of security fixes, and its maintainers are asking all users to upgrade as soon as practical. The update pairs the software patch with a second task for operators: reviewing the credentials that allow remote commands on their nodes, a step the maintainers describe as separate from installing the new version. It combines hardening of the plugin that handles remote commands with changes to how nodes evaluate channel opens and payment conditions.

This is the third consecutive point release shipped without an embargo period. Versions 26.06.8 and 26.06.9 followed the same approach, with fixes made public immediately. As with those releases, maintainers have again withheld the tests tied to the security fixes. According to the release notes, this makes it harder to turn the fixes into working exploits and gives users more time to upgrade. The disclosure model also sets the stakes for operators: once a release is public, so are the weaknesses it addresses, meaning a node that lags behind is running software with documented flaws.

Credential Review Added to the Upgrade Checklist

Runes and commando sit at the center of this update's security work. Commando lets a directly connected peer ask a node to run a command, and the peer generally needs a rune — an authorization credential — to do so.

The update closes a way to get around rune limits on parameter names by using duplicate or punctuation-variant names. It also fixes a commando crash caused by reusing a command ID after a failed command. Oversized runes are now rejected outright; previously, the software could spend quadratic time decoding them.

Maintainers recommend binding each rune used over commando to the node ID of the app that uses it. With this id restriction in place, the rune cannot be used from anywhere else. Operators are also told to blacklist any runes they cannot account for using the blacklistrune command, and to then issue new runes with tighter restrictions. Read together, the steps amount to an audit of every credential that can trigger remote commands on a node, with unexplained runes revoked before replacements are issued.

Channel and Payment Fixes

The new version checks a peer's transaction signatures during dual-funded channel opening and splicing, the operation that adjusts a channel's funds without closing it. This follows the Lightning protocol's BOLT 2 specification, which covers channel establishment and normal peer-to-peer operation, according to the changelog.

Another fix deals with a conditional payment contract known as an HTLC. A just-removed HTLC could be confused with a live one sharing its payment hash, amount and expiry, causing the node to fail the live payment while its peer could still claim it.

Channel-open handling is also stricter. Nodes now refuse channel opens when a peer proposes a dust limit — the threshold under which outputs are treated as dust — above 5,000 satoshis; the changelog says the old behavior let a peer trim the node's balance into fees during a forced close. For dual-funded opens, a peer's dust limit above the channel reserve is also refused, and a v2 zero-confirmation open — a channel that goes live before its funding transaction is confirmed — is refused unless the operator has set the node to accept one from that peer. Dual funding remains experimental, and maintainers discourage zero-confirmation channels with peers that are not trusted.

Other changes give a safe default reply when a plugin hook fails, instead of a crash or hang. Splice fee bumps now use at least 25/24 of the prior feerate, which peers such as Eclair require. Nodes that have run development builds cannot downgrade to the 26.06.x series because their database schema is newer. The release ships reproducible binaries for Ubuntu 22.04, 24.04 and 26.04, plus Docker images.

Disclosure and Release Timing

The flaws fixed in this release were reported by nearly 20 named sources, including The Bitcoin Red Team, Matt Morehouse and Niklas Gögge. Others asked not to be named.

GitHub lists a Nov. 4 release date for the version, while its tagged changelog shows Nov. 5. The update follows a separate stored-trigger crash disclosed on Nov. 2. At the time of reporting, bitcoin traded near $76,002, down 5.29% over 24 hours.