Core Lightning, l’une des implémentations majeures du réseau Bitcoin Lightning, demande à tous ses utilisateurs d’installer sans délai la version 26.06.10. Cette mise à jour corrige plusieurs failles touchant la sécurité des canaux, la résolution des paiements et l’accès distant aux commandes des nœuds. Le risque principal décrit est un drainage de la balance par frais, sans exploitation documentée à ce stade.
🔑 En bref
- Core Lightning 26.06.10 corrige des failles sur la validation des canaux, la résolution des HTLC et l’interface commando.
- La limite de poussière proposée par un pair est désormais refusée au-delà de 5 000 satoshis lors de l’ouverture d’un canal.
- Les runes d’accès déjà délivrées doivent être revues, liées au node ID visé et, si besoin, placées sur liste noire.
- La source ne documente ni exploitation, ni montant perdu, ni nombre de nœuds touchés.
Trois fronts de correction
La version 26.06.10 touche trois surfaces logicielles : la validation des canaux, la gestion des contrats conditionnels HTLC et l’interface commando, qui permet d’exécuter des commandes à distance sur un nœud. Le tableau ci-dessous synthétise les points corrigés et les actions attendues des opérateurs.
| Surface | Correctif | Action opérateur |
|---|---|---|
| Canaux à financement dual et épissage | Vérification des tx_signatures du pair (BOLT 2) | Installer 26.06.10 |
| Contrats HTLC | Suppression confuse d’un HTLC encore actif | Installer 26.06.10 |
| Limite de poussière | Refus au-delà de 5 000 satoshis | Installer 26.06.10, aucune action distincte documentée |
| Commando et runes | Restrictions de pname, crash, runes surdimensionnées | Revoir, lier et placer sur liste noire les runes |
Validation des signatures et épissage
La mise à jour ajoute une vérification des tx_signatures transmises par un pair lors de l’ouverture d’un canal à financement dual, ainsi que lors d’un épissage (splicing), c’est-à-dire la modification d’un canal existant sans le fermer. Cette vérification est conforme à la spécification BOLT 2 du protocole Lightning, qui définit les règles d’échange de messages entre nœuds.
Résolution des HTLC
Un HTLC (Hash Time-Locked Contract) est un contrat conditionnel Bitcoin qui subordonne le transfert de fonds à la révélation d’un secret et au respect d’une échéance. Le correctif traite un cas où un HTLC venait d’être supprimé alors qu’il pouvait être confondu avec un HTLC toujours actif partageant le même hash de paiement, le même montant et la même date d’expiration. Le nœud pouvait alors faire échouer en amont un paiement encore actif, alors que son pair demeurait en mesure de le réclamer.
Limite de poussière et risque de drainage
La limite de poussière (dust limit) désigne le montant en dessous duquel une sortie n’est pas matérialisée on-chain lors de la fermeture d’un canal. La version 26.06.10 refuse désormais l’ouverture d’un canal lorsque le pair propose une limite supérieure à 5 000 satoshis, soit 0,00005 BTC. Selon le journal des modifications, le comportement précédent permettait à un pair de réduire la balance du nœud en frais lors d’une fermeture forcée.
- Pour les canaux à financement dual, la limite du pair est également rejetée lorsqu’elle dépasse la réserve du canal.
- Le mécanisme refusé constitue le principal risque de drainage décrit par la source.
- La source ne documente aucun cas d’exploitation de ce mécanisme.
Accès distant : commando et runes
Le second volet concerne l’interface commando. Selon la documentation officielle, un pair directement connecté peut demander au nœud d’exécuter une commande, laquelle nécessite généralement une rune, c’est-à-dire un identifiant d’autorisation qui limite les actions permises.
« Commando sends a directly connected peer a request to execute a command; the peer generally requires a rune authorizing that command. »
Documentation officielle de Core Lightning, interface commando
La version corrige trois points. Le premier empêche le contournement des restrictions de la rune pname grâce à des noms de paramètres dupliqués ou légèrement modifiés dans leur ponctuation. Le deuxième corrige un plantage de commando provoqué par la réutilisation de l’identifiant d’une commande après l’échec de celle-ci. Le troisième refuse désormais les runes surdimensionnées, qui consommaient auparavant un temps de décodage quadratique.
La mise à jour ne suffit toutefois pas à sécuriser les accès distants déjà en place. Les mainteneurs demandent aux opérateurs de revoir séparément les runes délivrées et de les associer au nœud auquel elles sont réellement destinées.
« Install v26.06.10 and review commando runes: bind them to the intended node and replace credentials you cannot account for. »
Mainteneurs de Core Lightning, journal de modifications
Mesures recommandées
Les recommandations de gestion précisent la marche à suivre pour un opérateur qui utilise commando :
- Installer la version 26.06.10 sur chaque nœud concerné.
- Lier chaque rune utilisée via commando à l’identifiant du nœud de l’application autorisée, au moyen d’une restriction id.
- Mettre sur liste noire, avec la commande blacklistrune, les runes que l’opérateur ne parvient pas à justifier.
- Remplacer ces identifiants par des runes soumises à des restrictions plus strictes.
Financement dual et canaux à zéro confirmation
Le financement dual demeure expérimental. Les mainteneurs découragent l’usage de canaux à zéro confirmation (zero-conf) avec des pairs non fiables. La nouvelle version refuse aussi l’ouverture d’un canal zero-conf de version 2, sauf si l’opérateur a explicitement configuré l’acceptation de ce type de canal pour le pair concerné. Cette restriction par défaut réduit la surface d’attaque, mais elle impose aux opérateurs de vérifier leur configuration existante.
Calendrier et zones d’ombre
La version 26.06.10 fait suite aux correctifs de sécurité de la version 26.06.9. Elle intervient également après un crash distinct de type « stored-trigger », daté du 2 novembre. La date de sortie présente une légère contradiction : GitHub indique le 4 novembre, tandis que le journal de modifications la fixe au 5 novembre. Aucune année n’est précisée.
Les mainteneurs ont décidé, à titre temporaire, de ne pas diffuser les tests associés aux correctifs. Cette décision vise à retarder la transformation des correctifs en exploits fonctionnels et à laisser davantage de temps aux opérateurs. Les nœuds qui exécutent la branche master ne peuvent en revanche pas revenir à la série 26.06.x, leur schéma de base de données étant plus récent que celui attendu par cette série.
La source ne fournit ni nombre de nœuds concernés, ni montant volé ou perdu, ni mesure de trafic, ni annonce d’une attaque réussie. Le schéma qu’elle présente illustre deux surfaces logicielles documentées, avec des flèches représentant des requêtes et des opérations de maintenance. Il ne représente ni transferts de Bitcoin, ni trafic mesuré, ni test d’accès réel. Aucune réaction de marché, aucune évolution de prix et aucun volume de marché ne sont signalés.
Conclusion et scénarios
Le scénario central est une adoption rapide de la version 26.06.10 par les opérateurs de nœuds, qui réduirait fortement l’exposition aux failles de validation des canaux et de résolution des HTLC. Le risque résiduel se concentre alors sur les runes commando déjà diffusées à des applications tierces, dont le nombre n’est pas quantifié par la source.
Dans un scénario défavorable, une mise à jour tardive laisserait ouverts les accès distants mal liés à un nœud précis. Le report de la publication des tests offre une fenêtre aux opérateurs, mais il ne remplace ni la mise à jour ni la révision des identifiants. Les signaux à suivre sont la publication ultérieure des tests, tout rapport d’incident après correctif et la clarification de la date de sortie.
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.
