Faille de sécurité Core Lightning : ce que les exploitants de nœuds doivent faire

Si vous exploitez votre propre nœud Lightning avec le logiciel Core Lightning, une seule tâche s’impose aujourd’hui : la mise à jour vers la version 26.06.7. Blockstream indique avoir livré cette version le 28 août 2026. Elle corrige plusieurs failles de sécurité confirmées, et toutes les éditions antérieures sont depuis considérées comme non prises en charge. Si vous ne pouvez pas mettre à jour immédiatement, redémarrez le nœud avec l’option --offline. L’une comme l’autre prend quelques minutes, et l’une comme l’autre s’avère plus efficace que le réflexe qui vient d’abord à l’esprit : éteindre la machine.

Si en revanche vous détenez du Bitcoin sur une plateforme, dans un portefeuille ordinaire ou dans une application, sans exploiter vous-même de nœud, l’avertissement ne vous concerne pas directement. Il vise la machine qui gère vos canaux de paiement. Qui n’en exploite aucune n’a rien à mettre à jour. Le coup d’œil reste néanmoins utile : l’épisode montre à quelle vitesse une erreur de programmation signalée devient une échéance datée, et il se répète actuellement à intervalles rapprochés.

Ce qui s’est passé : Core Lightning confirme des failles et livre une mise à jour d’urgence

Core Lightning, ou CLN en abrégé, est l’une des différentes implémentations logicielles du réseau Lightning. Le réseau Lightning est une seconde couche au-dessus de la chaîne de blocs Bitcoin : deux parties verrouillent ensemble un montant dans une transaction, puis règlent entre elles autant de fois qu’elles le souhaitent, sans inscrire chaque paiement séparément dans la chaîne. Cette liaison verrouillée s’appelle un canal de paiement. Le logiciel qui gère un tel canal, le surveille et le défend en cas de litige porte le nom de nœud.

Fin août, l’équipe de CLN a annoncé publiquement avoir traité pendant des semaines un nombre inhabituellement élevé de signalements de failles produits à l’aide d’outils d’intelligence artificielle. Plusieurs d’entre eux se sont révélés authentiques. La consigne du projet sur son propre canal était brève et allait à l’encontre de la première intuition : n’éteignez surtout pas le nœud, redémarrez-le plutôt avec --offline, car cette option coupe les connexions vers les autres nœuds et ferme ainsi la voie d’attaque.

Les récits divergent sur le déroulement exact, et cela mérite d’être signalé, car l’appréciation de la durée pendant laquelle les failles sont restées ouvertes en dépend. Le service spécialisé CryptoSlate date l’arrivée des premiers signalements produits par intelligence artificielle au 13 août et une première annonce du projet au 23 août. D’autres comptes rendus, dont celui de TFTC, situent l’avertissement public au 26 août et évoquent une dizaine de jours de délai. La fin de cette chaîne est documentée et incontestée : le 28 août, la version corrigée était disponible sous la forme d’un fichier signé.

Aucune perte n’a été signalée à ce jour

Selon l’état des informations au moment de la divulgation, il n’y a eu aucune perte de fonds confirmée ni aucun cas connu d’exploitation effective de l’une des failles. Il s’agit d’un instantané et non d’une levée d’alerte : le cœur technique des défauts reste sous scellés jusqu’à la mi-septembre, et ce n’est qu’ensuite que l’on pourra vérifier de manière indépendante l’ampleur réelle de la fenêtre.

Suis-je concerné ? La réponse dépend de qui exploite votre nœud

L’avertissement porte sur le logiciel Core Lightning. Les autres implémentations du réseau Lightning ne sont pas citées dans le communiqué du projet. Pour vous, la question se tranche selon une ligne simple :

• Vous exploitez votre propre nœud avec Core Lightning, sur un petit serveur domestique, une machine louée ou un ensemble prêt à l’emploi comme Umbrel ou Start9 : vous êtes visé. Mise à jour ou --offline, aujourd’hui.
• Vous exploitez votre propre nœud avec une autre implémentation : cet avertissement ne s’adresse pas à vous. Une discipline générale de mise à jour reste néanmoins judicieuse, car les signalements de ce type se succèdent actuellement à un rythme soutenu.
• Vous utilisez un portefeuille Lightning sur votre téléphone dont le nœud est exploité par un tiers : l’obligation de mise à jour incombe alors à ce prestataire et non à vous. Vous reconnaissez ces offres au fait que vous ne mettez jamais de logiciel à jour et ne payez jamais vous-même l’ouverture d’un canal. Quel portefeuille suit quelle voie, notre comparatif des portefeuilles logiciels le détaille.
• Vous détenez du Bitcoin uniquement sur une plateforme ou sur un appareil matériel, sans utiliser Lightning : l’épisode ne touche pas votre solde.

Cette distinction compte davantage qu’il n’y paraît. Les avertissements de ce type sont vite raccourcis en informations portant sur l’ensemble du réseau Lightning. Le cercle des destinataires est plus étroit : il regroupe les exploitants d’un logiciel précis dans une édition précise.

Version 26.06.7 : pourquoi les éditions antérieures ne sont plus prises en charge

La version corrigée porte le numéro 26.06.7. La note du projet à ce sujet est brève et sans détour : les éditions antérieures à 26.06.7 ne sont plus prises en charge. Cela ne signifie pas qu’un nœud plus ancien s’arrête, puisqu’il continue techniquement de fonctionner. Cela signifie qu’aucune correction de sécurité n’arrivera plus pour ces états et qu’une voie d’attaque connue restera ouverte dès la publication du code source.

Sur la date, la précision est utile, car les indications divergent légèrement : l’article de blog de Blockstream est daté du 28 août 2026, tandis que dans la boutique d’applications Umbrel la même version porte la date du 29 août. L’écart s’explique par le passage par les sources de paquets et ne change rien au fond. C’est le numéro qui compte, pas le jour.

La prochaine version régulière, numérotée 26.09, reste prévue pour la fin septembre selon le projet. Qui passe aujourd’hui à 26.06.7 devra donc y revenir dans quelques semaines. Cela plaide pour aménager proprement une bonne fois la procédure de mise à jour au lieu de la chercher à chaque occasion.

Vérifier la signature : comment établir que le fichier provient du projet

La consigne du projet, traduite littéralement, se lit ainsi : vérifier les signatures des fichiers, installer, redémarrer. Cet ordre n’a rien d’accessoire. Une signature est un paraphe cryptographique par lequel les développeurs confirment qu’un fichier vient d’eux sans modification. Sans cette vérification, une mise à jour de sécurité constituerait l’appât idéal : l’utilisateur attend un nouveau fichier, le cherche activement et l’installe avec des droits étendus.

La raison est ici particulièrement concrète. Comme le code source est retenu, personne ne peut retracer pendant les deux premières semaines ce que contient le fichier. La signature constitue donc provisoirement le seul indice de provenance. Qui met à jour par un ensemble prêt à l’emploi ne télécharge pas lui-même et laisse cette vérification au fournisseur du paquet, ce qui déplace la tâche sans la supprimer.

La seconde vérification vient plus tard

Dès que le code source sera accessible, le logiciel pourra être reconstruit à partir de celui-ci et comparé au fichier qui aura tourné pendant deux semaines. Si les deux concordent, il sera établi a posteriori que le fichier signé ne contenait rien d’autre que ce que le projet a publié. Cette seconde étape est à la portée de chacun, et c’est précisément sur elle que repose l’engagement du projet.

Ce que l’option --offline désactive réellement sur un nœud Lightning

L’option --offline est un paramètre de démarrage du logiciel de nœud. Le projet en décrit ainsi l’effet : elle supprime la voie d’attaque en ôtant aux attaquants toute possibilité de s’adresser au nœud, pendant que le programme continue de fonctionner et de lire la chaîne de blocs afin de détecter les tentatives de fraude.

En pratique, cela signifie que le nœud n’accepte plus de connexions extérieures et n’en établit aucune de lui-même. Vous ne pouvez ni envoyer ni recevoir de paiements, et les paiements acheminés par d’autres ne transitent plus par vous. En revanche, tout ce qui se produit sur la chaîne de blocs reste visible pour votre nœud, qui peut y réagir.

Le prix est donc clairement énoncé : la disponibilité de vos canaux cesse tant que l’option est activée. Pour un nœud privé, c’est un désagrément. Pour un nœud par lequel transitent régulièrement des paiements de tiers, c’est un manque à gagner. CryptoSlate souligne qu’un nombre suffisant de mises à jour tardives et de nœuds éteints pourrait réduire sensiblement la capacité d’acheminement dans certaines parties du réseau.

Pourquoi éteindre la machine vaut moins que le mode hors ligne

C’est ici que des conseils bien intentionnés causent des dégâts. La réaction évidente à un avertissement de sécurité consiste à éteindre l’appareil. Sur un nœud Lightning, c’est la moins bonne des deux possibilités, et la raison tient à la construction des canaux de paiement.

Un canal de paiement est garanti par le dernier solde signé conjointement. Chaque partie peut fermer le canal unilatéralement à tout moment via la chaîne de blocs, ce que l’on appelle une fermeture forcée. Si une contrepartie y présente un ancien solde qui lui est plus favorable, il s’agit d’une tentative de fraude. Un délai de contestation protège contre cela : dans une fenêtre convenue, la partie lésée peut présenter une transaction de pénalité et reçoit alors l’intégralité du contenu du canal.

Ce délai court en temps de blocs et non en temps calendaire, et il court indépendamment de l’état de votre machine. Un nœud éteint ne lit pas la chaîne de blocs, ne remarque pas la tentative de fraude et laisse passer le délai. C’est exactement ce que le projet vise en affirmant qu’un nœud éteint ne peut pas remplir cette fonction. Le mode hors ligne, lui, laisse le programme tourner et la chaîne être lue, et retire seulement les connexions.

Qui utilise une tour de garde dispose d’une marge

Une tour de garde est un service de surveillance qui observe la chaîne de blocs à votre place et présente la transaction de pénalité en cas de fraude pendant que votre propre nœud dort. Qui a mis en place un tel service se trouve en meilleure position lors d’une interruption. Vous ne devriez pas vous y fier, car de nombreux nœuds privés fonctionnent sans, et sa mise en place n’a rien d’une étape accessoire.

Umbrel et Start9 : comment la mise à jour parvient aux nœuds en un clic

De nombreux nœuds privés reposent sur des ensembles prêts à l’emploi dotés d’une interface plutôt que sur la ligne de commande. Vous n’y trouverez pas --offline sous forme de bouton dans le tableau de bord ; c’est un paramètre de démarrage de l’application. Le passage par la boutique d’applications a donc ici une histoire propre, que l’entrée Umbrel permet de bien suivre.

Une version intermédiaire numérotée 26.06.6-patch.1 y est d’abord apparue le 27 août. Sa note expliquait que le nœud continuait de fonctionner et de surveiller la chaîne de blocs Bitcoin, mais qu’il ne pouvait provisoirement ni envoyer, ni recevoir, ni acheminer de paiements Lightning. La consigne qui l’accompagnait était nette : laisser Core Lightning tourner et ne pas le supprimer, la mise à jour suivante paraîtrait comme d’habitude dès que la correction serait prête.

Le 29 août est ensuite arrivée la 26.06.7, accompagnée de la mention qu’il s’agissait d’une mise à jour de sécurité importante et que le nœud se reconnecterait ensuite automatiquement au réseau Lightning. Pour les utilisateurs de tels ensembles, cela signifie deux choses. Le mode hors ligne est peut-être déjà arrivé automatiquement, sans que personne n’ait actionné d’option. Et le fonctionnement complet ne revient qu’avec la seconde mise à jour. Si vous vous étonnez depuis quelques jours qu’un paiement ne passe pas, l’explication est là.

Code source seulement le 11 septembre : ce que cache l’embargo

Un embargo désigne ici un délai de confidentialité convenu pendant lequel les détails techniques d’une faille ne sont pas publiés. La pratique est courante entre le déclarant et l’éditeur avant la correction. Ici, le cas diffère : la correction est déjà livrée, et le code source reste malgré tout sous scellés jusqu’au 11 septembre 2026, soit quatorze jours après la livraison.

La justification est pratique. À partir d’une correction publiée, on peut remonter au défaut qu’elle répare. Qui dispose du code source voit quelles lignes ont changé et sait souvent plus vite que le défenseur où l’attaque prend appui. Le compte rendu de TFTC attribue cette justification au développeur principal de CLN, Christian Decker : les détails techniques sont retenus précisément pour empêcher les attaquants d’en tirer une attaque opérationnelle.

On peut objecter que le logiciel libre tire justement sa vérifiabilité de ce que chacun peut en suivre le contenu. Pendant deux semaines, un fichier tourne sur les nœuds dont personne à l’extérieur du projet ne peut retracer le contenu. Les deux camps ont un argument, et tous deux se rapportent à la même période. Le litige ne pourra être tranché qu’après le 11 septembre, lorsque la comparaison entre le code source et le fichier livré deviendra possible.

Signalements de failles produits par IA : le schéma derrière l’urgence

Le déclencheur de cet épisode est aussi remarquable que son déroulement. Les défauts ne proviennent pas d’un audit planifié. Ils sont arrivés sous la forme d’un flot de signalements produits avec des outils d’intelligence artificielle. Une partie était sans valeur, une partie était authentique, et distinguer les deux a coûté des semaines au projet.

Pour un logiciel entretenu bénévolement, c’est une charge inédite. Qui reçoit des signalements doit examiner chacun d’eux, car une trouvaille authentique laissée de côté serait l’erreur la plus coûteuse. Dans le même temps, l’effort du côté de ceux qui produisent de tels signalements tend vers zéro. Le rapport entre l’attaque et la défense s’en trouve sensiblement déplacé.

Core Lightning n’est pas un cas isolé. TFTC inscrit l’épisode dans une série et cite comme exemple antérieur le 3 août, date à laquelle le service d’échange Boltz a suspendu ses swaps en invoquant des attaques assistées par intelligence artificielle. Qui a suivi les dernières semaines connaît aussi ce schéma du côté du matériel : nous avons récemment décrit comment BitBox02 a comblé trois failles de sécurité avec le micrologiciel 9.26.5 et pourquoi, chez Coldcard, l’ancienne graine ne devrait pas systématiquement être réutilisée après une mise à jour du micrologiciel. La rapidité avec laquelle vous installez une mise à jour de sécurité est ainsi passée du sujet marginal à la routine.

Ce que l’incident signifie pour la conservation de vos bitcoins

Un épisode de ce genre n’implique pas que l’autoconservation soit une erreur. Il en découle une répartition qui vaut indépendamment de ce cas : un nœud Lightning est un appareil relié en permanence au réseau, qui accepte les connexions d’inconnus et a besoin de clés pendant son fonctionnement. Un tel système reste un système chaud, quel que soit le soin qu’on lui porte.

Il en résulte une répartition simple de vos avoirs. Dans le canal de paiement se trouve le montant dont vous avez réellement besoin pour payer. Tout ce qui va au-delà relève d’une conservation dont les clés ne se trouvent jamais sur une machine connectée au réseau, telle que la décrit notre comparatif des portefeuilles matériels. Le devoir qui l’accompagne est la sauvegarde des mots de récupération, sur laquelle nous avons rassemblé ce que l’acier, la phrase de passe et le multisignature apportent réellement.

La seconde conclusion porte sur la vitesse. Entre l’avertissement et la version corrigée, il s’est écoulé environ deux jours selon les indications disponibles. Qui n’a pas connaissance de l’avertissement pendant ce laps de temps, parce qu’il ne suit ni le projet ni sa source de paquets, sort de la fenêtre. Un canal de notification bien établi relève de l’équipement d’une infrastructure autogérée et non de son confort.

Vérifier la faille Core Lightning : ce qu’il faut retenir

1. Vérifiez aujourd’hui la version de votre nœud et passez à la 26.06.7. Si ce n’est pas possible immédiatement, redémarrez avec --offline et effectuez la mise à jour ensuite. Si vous ignorez quel logiciel se trouve derrière votre paiement Lightning, le comparatif des portefeuilles logiciels le clarifie.
2. Séparez proprement les avoirs chauds et froids. Reste dans le canal ce dont vous avez besoin pour payer, le reste part vers une conservation sans connexion permanente au réseau. Quels appareils y parviennent, le comparatif des portefeuilles matériels l’indique.
3. Notez la date du 11 septembre. Ce jour-là, le code source sera publié ; ce n’est qu’ensuite que le fichier exécuté pourra être vérifié et la portée des failles appréciée. Les outils permettant de garder avoirs et événements en vue sont réunis dans notre panorama des plateformes d’analyse.

Les éléments solides figurent dans le communiqué du projet sur la version 26.06.7 (Blockstream, 28 août 2026) et dans l’entrée de la boutique d’applications Umbrel accompagnée des notes sur les deux mises à jour (Umbrel App Store).

(Au 30 août 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)