Core Lightning, one of the main implementations used to run payment nodes on the Bitcoin Lightning Network, is urging all users to install version 26.06.10 as soon as possible. The release fixes several flaws affecting channel security, payment resolution and remote access to node commands. The main drain risk described involves fees charged against a node’s balance during a forced closure, with no documented exploit so far.
🔑 Key takeaways
- Core Lightning 26.06.10 fixes flaws in channel validation, HTLC resolution and the commando interface.
- A peer’s dust limit above 5,000 satoshis is now rejected when a channel is opened.
- Runes already issued should be reviewed, bound to the intended node ID and, where necessary, blacklisted.
- The source documents no exploit, no lost funds and no count of affected nodes.
Three fronts of the fix
Version 26.06.10 touches three software surfaces: channel validation, the handling of HTLCs (hash time-locked contracts) and the commando interface, which lets a node execute commands sent by a connected peer. The table below summarizes each fix and the action expected from operators.
| Surface | Fix | Operator action |
|---|---|---|
| Dual-funded channels and splicing | Verification of the peer’s tx_signatures (BOLT 2) | Install 26.06.10 |
| HTLC contracts | Confusable active HTLC no longer dropped | Install 26.06.10 |
| Dust limit | Rejection above 5,000 satoshis | Install 26.06.10, no separate action documented |
| Commando and runes | pname restrictions, crash, oversized runes | Review, bind and blacklist runes |
Signature checks and splicing
The update adds a check on tx_signatures sent by a peer when a dual-funded channel is opened, as well as during splicing, the process of modifying an existing channel without closing it. The verification follows the BOLT 2 specification of the Lightning protocol, which defines how nodes exchange these messages.
HTLC resolution
An HTLC is a conditional Bitcoin contract that makes a transfer contingent on revealing a secret and meeting a deadline. The fix addresses a case where an HTLC had just been removed even though it could be confused with a still-active HTLC sharing the same payment hash, amount and expiry. In that situation the node could fail an active payment upstream, even though its peer remained able to claim it.
Dust limit and drain risk
The dust limit is the amount below which an output is not materialized on-chain when a channel closes. Version 26.06.10 now refuses to open a channel if the peer proposes a dust limit above 5,000 satoshis, or 0.00005 BTC. According to the changelog, the previous behavior allowed a peer to reduce the node’s balance through fees during a forced closure.
- For dual-funded channels, the peer’s dust limit is also rejected when it exceeds the channel reserve.
- This refused mechanism is the main drain risk described by the source.
- The source does not document any exploitation case involving this mechanism.
Remote access: commando and runes
The second part concerns the commando interface. According to the official documentation, a directly connected peer can ask the node to execute a command, which generally requires a rune, meaning an authorization identifier that limits the actions allowed.
“Commando sends a directly connected peer a request to execute a command; the peer generally requires a rune authorizing that command.”
Core Lightning official documentation, commando interface
The release fixes three issues. The first prevents bypassing the restrictions of the pname rune through duplicated parameter names or names slightly altered in their punctuation. The second fixes a commando crash caused by reusing a command’s identifier after that command failed. The third now rejects oversized runes, which previously consumed decoding time that grew quadratically.
The software update alone does not secure remote access already in place. Maintainers ask operators to review the runes they have issued separately and to bind each one to the node it is actually meant for.
“Install v26.06.10 and review commando runes: bind them to the intended node and replace credentials you cannot account for.”
Core Lightning maintainers, changelog
Recommended measures
The maintainers’ management guidance sets out the steps for an operator who uses commando:
- Install version 26.06.10 on every affected node.
- Bind each rune used over commando to the node ID of the authorized application, using an id restriction.
- Blacklist with the blacklistrune command any rune the operator cannot justify.
- Replace those credentials with runes subject to tighter restrictions.
Dual funding and zero-conf channels
Dual funding remains experimental. The maintainers discourage using zero-confirmation (zero-conf) channels with untrusted peers. The new version also refuses to open a version 2 zero-conf channel unless the operator has explicitly configured acceptance of that channel type for the peer concerned. This default restriction reduces the attack surface, but it requires operators to check their existing configuration.
Timeline and open questions
Version 26.06.10 follows the security fixes in version 26.06.9. It also comes after a separate “stored-trigger” crash dated November 2. The release date is slightly inconsistent in the source material: GitHub lists November 4, while the changelog dates the same version November 5. No year is specified for either date.
On a temporary basis, the maintainers have decided not to publish the tests associated with the security fixes. The stated aim is to delay turning the fixes into working exploits and to give operators more time to install the update. Nodes running the master branch, however, cannot revert to the 26.06.x series, because their database schema is newer than the one that series expects.
The source gives no number of affected nodes, no amount stolen or lost, no traffic measurement and no announcement of a successful attack. The diagram it presents illustrates two documented software surfaces, with arrows representing requests and maintenance operations. It does not represent Bitcoin transfers, measured traffic or a real access test. No market reaction, price move or trading volume is reported.
Conclusion and scenarios
The central scenario is rapid adoption of version 26.06.10 by node operators, which would sharply reduce exposure to the channel validation and HTLC resolution flaws. The residual risk would then concentrate on commando runes already shared with third-party applications, whose number the source does not quantify.
In a less favorable scenario, delayed upgrades would leave remote access open for runes not tied to a specific node. The decision to withhold the tests gives operators a window, but it replaces neither the update nor the review of credentials. Signals to watch include the later publication of the tests, any incident report filed after the patch and a clarification of the release date.
Sources
Cet article est publié à titre informatif et éducatif. Il ne constitue en aucun cas un conseil en investissement. Faites vos propres recherches (DYOR) avant toute décision.
