Alerte Sécurité : Nœuds Core Lightning Anciens Attaqués

Un nœud Lightning laissé quelques semaines en retard peut-il vraiment devenir une cible, alors que le logiciel vient tout juste d’être corrigé ? La question n’est plus théorique. Le 2 octobre 2026, l’équipe de Core Lightning a publié un avertissement net : des attaquants s’en prennent déjà aux installations encore bloquées sur la version 26.06.7 ou sur une mouture plus ancienne. Le message tient en une consigne, presque sèche. Il faut passer à la dernière livraison, et le faire sans attendre. Derrière cette phrase courte se cache pourtant une série d’épisodes qui court depuis août, entre rapports générés par des modèles d’intelligence artificielle, correctifs publiés avec retenue, et un silence volontaire sur la nature exacte des failles.

Ce que l’alerte dit vraiment, et ce qu’elle tait

L’avertissement ne ressemble pas à un bulletin technique classique. Il ne nomme pas la vulnérabilité. Il ne donne pas de numéro de suivi. Il ne confirme pas non plus que des satoshis ont déjà quitté un portefeuille. Ce que l’équipe affirme, c’est qu’elle a reçu des signalements d’attaques dirigées contre des nœuds non mis à jour. Le reste demeure dans l’ombre, volontairement. Pour un opérateur qui fait tourner un routage de paiements, ce silence pèse autant que l’alerte elle-même.

La formulation officielle, reprise et reformulée ici sans en garder le tour, tient en une injonction : si la version installée est 26.06.7 ou antérieure, le passage à la livraison la plus récente doit être immédiat. Quelques semaines plus tôt, les développeurs avaient déjà sorti un autre train de correctifs. L’alerte d’octobre ne se contente donc pas de rappeler une vieille note. Elle change le statut du risque. On n’est plus seulement face à des failles confirmées en laboratoire. On est face à des tentatives observées sur le réseau.

Mise à jour de sécurité urgente : si vous faites tourner la version 26.06.7 ou une version plus ancienne, passez à la dernière livraison dès que possible.

Équipe Core Lightning, octobre 2026

Cette retenue sur le détail n’est pas un oubli. Depuis la fin de l’été, le projet a plusieurs fois choisi de retarder la publication de certains éléments, tests inclus, le temps que les opérateurs installent le correctif. L’idée est simple, et elle est ancienne dans la sécurité logicielle : publier trop tôt le diff, c’est offrir à un adversaire la carte du chemin inverse. Il lui suffit parfois de comparer deux versions pour deviner où se trouvait le trou. Tant que des nœuds restent en retard, cette carte reste dangereuse.

Pourquoi le flou n’est pas un détail secondaire

Un opérateur raisonnable voudrait savoir s’il doit craindre un crash, une saturation mémoire, ou une perte lors d’une fermeture de canal. L’alerte ne tranche pas. Elle dit seulement que des systèmes encore sur une vieille branche sont visés. Cette imprécision a une conséquence pratique : on ne peut pas se rassurer en se disant que son usage personnel échappe au scénario décrit. Tant que le scénario n’est pas décrit, la seule parade documentée reste la mise à jour.

Le doute porte aussi sur la chronologie. Les correctifs de la 26.06.8 datent du 22 septembre. L’alerte publique arrive dix jours plus tard. Rien n’indique si les attaquants exploitent l’une des failles alors corrigées, ou un problème plus ancien, encore présent sur les branches précédentes. Les deux lectures restent ouvertes. C’est précisément pour cela que la consigne vise toute version égale ou antérieure à 26.06.7, et non une seule build.

Une saison de correctifs, pas un incident isolé

Pour comprendre le ton d’octobre, il faut revenir à août. Le projet a alors confirmé plusieurs vulnérabilités après avoir passé au crible une vague de signalements produits, pour une large part, par des modèles d’intelligence artificielle. Tous les rapports n’étaient pas fondés. Plusieurs l’étaient. La version 26.06.7, sortie le 28 août, répondait à ce travail. Son code source a d’abord été retenu environ deux semaines, le temps de laisser les opérateurs installer le binaire avant que des tiers puissent étudier le diff.

Pendant cette fenêtre, une option de repli existait. Un nœud pouvait tourner en mode hors ligne : coupé de ses pairs Lightning, incapable d’envoyer, de recevoir ou de router un paiement, mais toujours capable de surveiller la chaîne Bitcoin. L’intérêt de ce mode n’est pas anecdotique. Un démon complètement arrêté ne voit plus les transactions liées aux canaux. Un démon en veille partielle continue, lui, de guetter les mouvements qui pourraient forcer une réaction.

À ce stade d’août et de début septembre, le projet n’avait pas publié de preuve d’exploitation réussie, ni de perte d’utilisateurs liée aux failles confirmées. C’est ce point qui bascule avec l’alerte d’octobre. Le statut passe de « failles corrigées, exploitation non démontrée » à « des attaques contre les nœuds non patchés nous ont été signalées ». Le succès de ces attaques, et l’existence de pertes, restent non documentés.

Septembre, les fonctions expérimentales et la 26.06.8

Le 16 septembre, une autre note est venue s’intercaler. L’équipe indiquait examiner des signalements liés à des fonctions expérimentales. Le problème, disait-elle, pouvait toucher les fonds des utilisateurs. Le détail n’a pas été donné tout de suite. Six jours plus tard, la 26.06.8 sortait, avec des corrections de bogues et des rustines couvrant des vulnérabilités signalées de façon responsable.

Les notes de version créditent le Bitcoin Red Team, douze chercheurs ou groupes nommés, et des personnes ayant choisi l’anonymat. La recommandation d’installer la livraison était forte. Il n’y avait pas, cette fois, de période d’embargo sur la mise à jour elle-même. En revanche, une petite série de tests a été temporairement tenue à l’écart du dépôt public, toujours pour compliquer le travail de rétro-ingénierie pendant que les nœuds migraient.

Le journal des modifications permet d’identifier plusieurs familles de correctifs, sans qu’on puisse les relier une à une à l’alerte d’octobre. L’une pouvait faire tomber le nœud d’un expéditeur. Une autre concernait des requêtes capables d’épuiser la mémoire via l’interface REST. Une troisième touchait la fermeture de canal : dans certaines conditions, l’utilisateur pouvait perdre des fonds au profit d’une pénalité. Ce dernier cas est le plus sensible, parce qu’il ne se contente pas d’interrompre un service. Il déplace de la valeur.

Ce que change une pénalité de fermeture

Sur Lightning, un canal est un contrat à deux. Chacun détient une vue de l’état. Si l’un publie un état périmé, l’autre dispose en principe d’une fenêtre pour le contester et récupérer les fonds, parfois avec une pénalité. Le mécanisme protège contre la triche. Il devient dangereux dès qu’un bogue pousse un nœud honnête à publier, ou à laisser publier, un état qui sera lu comme frauduleux.

Le correctif de septembre visait précisément ce type de situation : sous certaines conditions, la fermeture pouvait aboutir à une perte subie comme une pénalité. L’alerte d’octobre ne dit pas que c’est ce chemin qui est emprunté aujourd’hui. Elle ne dit pas le contraire non plus. Pour un opérateur, la distinction importe moins que la conséquence. Tant que la version vulnérable tourne, le scénario le plus coûteux reste dans le champ du possible.

Il faut aussi mesurer le délai. Une faille de plantage se voit vite : le processus s’arrête, les pairs se plaignent, les journaux s’emplissent. Une faille de fermeture peut rester silencieuse jusqu’au moment où un canal se ferme, parfois des jours ou des semaines après l’exposition. C’est une des raisons pour lesquelles « je n’ai rien vu » n’est pas une preuve de sécurité sur un nœud Lightning.

Le rôle ambigu des rapports produits par l’IA

La séquence d’août éclaire un changement de rythme dans la maintenance des logiciels ouverts. Des modèles capables de lire du code à grande échelle ont inondé les équipes de signalements. Une partie était du bruit. Une autre touchait juste. Le travail des mainteneurs n’a pas disparu : il s’est déplacé vers le tri, la reproduction, et la décision de ce qui mérite un correctif.

Ce déplacement a un coût. Chaque rapport sérieux immobilise des heures. Chaque rapport fantaisiste aussi, tant qu’il n’a pas été écarté. Sur un logiciel qui détient des canaux, le coût d’un faux négatif est plus élevé que le coût d’un faux positif. D’où la tentation, compréhensible, de patcher vite, puis de parler peu. L’alerte d’octobre s’inscrit dans cette logique : confirmer l’existence d’attaques, refuser le mode d’emploi.

Pour les opérateurs, la leçon est moins spectaculaire qu’elle n’en a l’air. Le flux de rapports ne va pas se tarir. Les fenêtres entre correctif et exploitation vont plutôt se resserrer. Un nœud mis à jour « le mois prochain, quand j’aurai le temps » n’est plus un retard anodin. C’est une exposition dont la durée se mesure désormais en jours.

Ce que la 26.06.8 a réellement couvert

Sans republier le journal ligne à ligne, on peut regrouper les correctifs connus en trois familles utiles à l’opérateur. La première touche la disponibilité : un pair peut, dans un cas précis, faire chuter le nœud qui envoie. La deuxième touche les ressources : l’interface REST peut être poussée à consommer la mémoire disponible. La troisième touche la valeur : une fermeture mal gérée peut se solder par une pénalité.

Ces trois familles n’ont pas le même public. Un routeur public, exposé à des pairs inconnus, craint surtout le plantage et l’épuisement mémoire. Un nœud de marchand, qui ferme souvent des canaux, craint davantage le scénario de pénalité. Un nœud domestique, peu routé, n’est pas à l’abri pour autant : il suffit d’un pair malveillant, ou d’un canal unique mal fermé, pour que le bogue devienne concret.

L’alerte d’octobre ne mappe pas ces familles sur les attaques signalées. Elle élargit même le périmètre : toute version jusqu’à 26.06.7 incluse est concernée par la consigne de migration. Autrement dit, rester sur la livraison d’août, déjà présentée comme un correctif de sécurité, ne suffit plus. Il faut la livraison postérieure à la série de septembre.

Lecture froide de la chronologie

Août : confirmation de vulnérabilités après tri de rapports, dont beaucoup venaient d’outils d’intelligence artificielle. 28 août : sortie de la 26.06.7, code source retenu environ deux semaines. Début septembre : publication du source une fois l’embargo levé. 16 septembre : examen d’un problème potentiel sur des fonctions expérimentales, avec un risque évoqué sur les fonds. 22 septembre : 26.06.8, correctifs, tests partiellement retenus, pas d’embargo sur l’installation. 2 octobre : signalements d’attaques contre les versions 26.06.7 et antérieures.

Cette ligne de temps ne prouve pas une exploitation de la 26.06.8 à rebours. Elle montre surtout que le projet enchaîne les réponses depuis plus d’un mois, et que le statut public est passé de la prévention à la constatation d’un ciblage. C’est ce changement de statut qui justifie le ton, plus que le nombre de lignes modifiées dans le dépôt.

Les autres incidents Lightning de 2026, à ne pas confondre

L’été a aussi frappé d’autres briques de l’écosystème. En août, BTCPay Server a averti d’un exploit actif sur les installations qui n’avaient pas migré vers la 2.4.2. La faille exposait des identifiants d’administration LND, les fameux macaroons, sur les déploiements vulnérables. Un macaroon d’administrateur ouvre des droits étendus sur le portefeuille Lightning associé. Une fois le secret obtenu, l’accès au nœud connecté devient un chemin direct.

Des fonds ont été vidés sur certains nœuds touchés. BTCPay Server a ensuite soutenu une prime de récupération de 10 %, plafonnée à 3 BTC si l’ensemble des actifs dérobés revenait. Toutes les livraisons antérieures à 2.4.2 étaient concernées, y compris les candidats de cette même version. Les portefeuilles on-chain, eux, n’étaient pas dans le périmètre.

Quelques jours plus tôt, Zeus Wallet avait coupé son infrastructure après une cyberattaque. L’éditeur a indiqué avoir contenu l’incident en quelques heures, puis maintenu les services hors ligne le temps d’un audit. Les fonds des clients n’auraient ni été perdus ni exposés, et l’enquête n’aurait pas identifié de vulnérabilité dans le logiciel de nœud Lightning. Les canaux de fournisseur de services fermés pendant l’épisode devaient être remplacés au redémarrage.

Ces deux affaires ne sont pas l’alerte Core Lightning. Elles rappellent seulement que 2026 a déjà accumulé des incidents sur la couche paiement : secret d’administration exposé d’un côté, infrastructure d’éditeur coupée de l’autre, et maintenant ciblage de binaires non patchés. Les confondre sert les rumeurs. Les distinguer sert les opérateurs.

Le rappel Bitcoin Core, autre logiciel, autre logique

En mai, Bitcoin Core a divulgué une vulnérabilité de haute sévérité, suivie sous le nom CVE-2024-52911. Elle pouvait permettre à un mineur de faire planter à distance des nœuds vulnérables. Le périmètre couvrait les versions postérieures à 0.14.0 et antérieures à 29.0. Le correctif était déjà dans Bitcoin Core 29.0 au moment de la divulgation publique.

Le défaut se situait dans l’interpréteur de script, pendant la validation d’un bloc. Un bloc invalide construit de façon particulière pouvait pousser un nœud à lire une zone mémoire déjà libérée. Pour déclencher le problème, il fallait produire un bloc spécial portant assez de preuve de travail pour atteindre la pointe de la chaîne. L’exploitation était donc coûteuse. Une exécution de code à distance était jugée possible, mais peu probable, à cause des contraintes sur les données de bloc.

Le parallèle avec Core Lightning s’arrête à la discipline de divulgation : patcher d’abord, détailler ensuite, parfois très peu. La mécanique, elle, n’a rien à voir. Un plantage de nœud Bitcoin par bloc spécial n’est pas une pénalité de fermeture de canal. L’alerte d’octobre concerne le logiciel de nœud Lightning, pas le client Bitcoin sous-jacent.

Qui est vraiment exposé

L’exposition ne se mesure pas au montant détenu en portefeuille froid. Elle se mesure à la version du démon, à la surface réseau, et à l’état des canaux. Un nœud qui route, qui expose une API, ou qui laisse des pairs ouverts sur une vieille build est dans le viseur décrit par l’équipe. Un nœud déjà migré vers la dernière livraison sort de ce viseur, du moins pour les signalements actuels.

Les installs oubliées sont les plus fragiles. Un petit routeur lancé au printemps, un nœud de test devenu production, une image Docker jamais reconstruite : autant de cas où la version affichée au démarrage n’a pas bougé depuis août. L’alerte vise exactement ce stock. Elle ne vise pas, sur la foi du texte publié, les opérateurs déjà passés à la livraison postérieure à la 26.06.7.

Reste une zone grise. Si l’attaque exploite un défaut corrigé seulement en 26.06.8, alors la 26.06.7 elle-même, pourtant présentée comme correctif d’août, reste insuffisante. C’est pourquoi la consigne ne dit pas « au moins 26.06.7 ». Elle dit « 26.06.7 ou plus ancien, passez au dernier ». La nuance est toute la consigne.

Ce que l’opérateur peut faire sans attendre le détail

La première action est d’identifier la version réellement en cours, pas celle que l’on croit avoir installée. La deuxième est de planifier l’arrêt contrôlé, la sauvegarde des états de canaux, puis le remplacement du binaire. La troisième est de vérifier, après redémarrage, que les pairs reviennent et que les canaux ne partent pas en fermeture inattendue. Rien de tout cela n’exige de connaître le nom de la faille.

Si la migration immédiate est impossible, le précédent d’août reste un repère, pas une garantie pour octobre. Le mode hors ligne coupait les pairs et les paiements, tout en laissant le démon surveiller la chaîne. Il réduisait la surface. Il ne corrigeait pas le logiciel. S’en servir comme solution durable, alors que des attaques sont signalées, revient à prolonger l’exposition au lieu de la fermer.

Un point souvent négligé : un nœud complètement stoppé ne surveille plus les transactions de canal. Sur Lightning, ne plus regarder la chaîne, c’est parfois laisser passer la fenêtre de contestation. Mieux vaut donc un démon à jour et connecté, ou à défaut un démon en veille qui voit encore les blocs, qu’une machine éteinte « par prudence » pendant plusieurs jours.

Mémoire, interface REST et surface d’administration

Parmi les correctifs identifiables, celui qui concerne la mémoire via REST mérite une lecture à part. Une interface d’administration exposée, même sur un réseau que l’on croit privé, devient un levier dès qu’une requête peut forcer une consommation anormale. Le nœud ne perd pas forcément des fonds dans ce scénario. Il peut simplement cesser de répondre, manquer une contestation, ou redémarrer dans un état dégradé.

L’affaire BTCPay de l’été montrait un autre chemin vers le même endroit : le secret d’administration. Ici, le chemin décrit dans le journal Core Lightning est différent, puisqu’il passe par la consommation de ressources. Les deux rappellent pourtant une règle unique. L’interface qui pilote le nœud ne doit pas être traitée comme un panneau secondaire. C’est une porte sur les canaux.

Rien n’indique que l’alerte d’octobre vise spécifiquement REST. Le rappeler évite de restreindre à tort le périmètre. Un opérateur qui fermerait seulement son API, tout en laissant un binaire 26.06.7 en place, n’aurait pas suivi la consigne publiée.

Planter l’expéditeur, une arme de disponibilité

L’autre correctif identifiable pouvait faire chuter le nœud d’un expéditeur. Dans un réseau de paiement, faire tomber un pair n’est pas seulement une nuisance. Cela peut interrompre un routage, forcer des réessais, ou pousser un opérateur pressé à relancer dans de mauvaises conditions. Sur un logiciel qui doit parfois réagir vite à une publication on-chain, un crash répété est déjà une attaque, même sans vol direct.

Ce type de défaut intéresse surtout celui qui veut dégrader un routeur, pas nécessairement celui qui veut vider un portefeuille. Il rappelle que la sécurité Lightning ne se résume pas au solde. Elle inclut la capacité à rester en ligne au moment où un canal exige une réponse. Un nœud riche et souvent à terre est plus fragile qu’un nœud modeste et stable.

Ce que les chercheurs ont apporté, sans romantiser

La 26.06.8 crédite un collectif connu, le Bitcoin Red Team, aux côtés de douze chercheurs ou groupes nommés et de signalements anonymes. Ce crédit dit une chose simple : une partie des défauts a été remontée avant d’être exploitée publiquement, ou du moins avant que le projet ne les documente. Il ne dit pas que toutes les attaques d’octobre passent par ces mêmes défauts.

La retenue sur certains tests va dans le même sens. Publier la preuve de concept en même temps que le correctif accélère les honnêtes et les malhonnêtes à la même vitesse. Retenir la preuve quelques jours laisse une avance à ceux qui mettent à jour. L’alerte du 2 octobre suggère que cette avance n’a pas été prise par tout le monde.

Pourquoi les vieux nœuds restent en ligne

Un logiciel de nœud n’est pas une application de téléphone. Le mettre à jour peut impliquer une fenêtre d’arrêt, une compatibilité de base de données, une procédure de sauvegarde que l’on n’a pas répétée depuis des mois. Beaucoup d’opérateurs repoussent donc, surtout quand les canaux sont stables et que les frais de routage tombent. L’alerte casse cet argument. La stabilité apparente ne dit rien sur une faille qui ne se déclenche qu’à la fermeture, ou que face à un pair précis.

Il y a aussi l’effet de la double livraison rapprochée. Qui a installé la 26.06.7 fin août peut croire avoir « fait le correctif de sécurité ». L’alerte dit le contraire : cette version fait encore partie du lot visé. Le message est inconfortable, parce qu’il demande un second geste à ceux qui pensaient être en règle.

Les images système et les paquets de distribution ajoutent un délai. Tant qu’un dépôt tiers n’a pas reconstruit le paquet, l’opérateur pressé hésite à compiler. Hésiter est compréhensible. Rester sur 26.06.7 après un signalement d’attaques l’est moins, dès lors que le projet désigne explicitement cette branche.

Fonds, canaux, et ce que l’on peut affirmer

Aucune phrase de l’alerte ne confirme une perte. Aucune ne l’exclut. Le seul cas de perte documenté dans la séquence récente reste le bogue de fermeture corrigé en septembre, décrit comme pouvant aboutir à une pénalité. L’incident BTCPay, distinct, a lui confirmé des drains, via un autre logiciel et un autre secret. Mélanger les deux chiffres serait une erreur.

Pour Core Lightning, le fait nouveau est le ciblage, pas le bilan. Un ciblage peut échouer. Il peut aussi réussir sans que l’équipe choisisse de le dire tant que les nœuds n’ont pas migré. Les deux attitudes existent dans l’histoire de la divulgation. Ici, le texte public s’arrête au signalement d’attaques.

Une lecture pour les marchands et les routeurs

Un marchand qui encaisse en Lightning dépend de la disponibilité de son nœud et de la validité de ses canaux. Un plantage au moment d’un paiement se voit à la caisse. Une fermeture punitive se voit plus tard, sur le solde. Les deux justifient la même migration. Le routeur public, lui, ajoute le risque de réputation : un nœud souvent à terre perd ses pairs, puis son trafic, puis l’intérêt économique de rester en ligne.

Les fournisseurs de liquidité et les services qui ouvrent des canaux pour des tiers portent une responsabilité supplémentaire. Leur retard de version expose leurs utilisateurs sans que ceux-ci puissent patcher à leur place. L’alerte ne les nomme pas. Elle les concerne dès qu’ils font tourner le logiciel visé.

Les portefeuilles qui embarquent un nœud, ou qui parlent à un nœud distant, héritent du même décalage. L’utilisateur final voit rarement le numéro de version. C’est pourtant ce numéro qui décide s’il est dans le lot décrit le 2 octobre. Demander la version à son hébergeur ou à son application n’est pas un réflexe de spécialiste. C’est le minimum dès qu’une alerte de ce type circule.

Ce que cette alerte dit du réseau, sans le dramatiser

Lightning n’est pas « cassé » parce qu’un logiciel de nœud publie un correctif. Le réseau repose sur plusieurs implémentations, et sur une chaîne Bitcoin qui continue de servir d’arbitre. Une faille dans Core Lightning n’est pas une faille du protocole dans son ensemble. Elle est une faille d’un logiciel que des opérateurs ont choisi, et qu’ils doivent maintenir.

En même temps, minimiser serait faux. Les canaux concentrent de la valeur hors de la cadence des blocs, avec des fenêtres de réaction courtes. Un bogue de fermeture y coûte plus cher qu’un bogue d’affichage. L’accumulation, en quelques mois, d’alertes sur Core Lightning, sur BTCPay et sur une infrastructure d’éditeur montre une surface réelle, pas un bruit de marché.

La réponse saine n’est ni l’abandon ni l’indifférence. C’est la discipline de version. Savoir ce que l’on fait tourner. Savoir qui publie les correctifs. Accepter qu’un logiciel qui tient des canaux se met à jour comme un logiciel qui tient des clés, pas comme un outil que l’on oublie dans un coin.

Questions encore ouvertes au 2 octobre

Quelle faille est réellement visée ? L’équipe ne le dit pas. Les attaques ont-elles abouti ? Elle ne le dit pas. Des fonds ont-ils bougé ? Elle ne le dit pas. Le problème examiné le 16 septembre sur les fonctions expérimentales est-il dans le lot ? Le texte d’octobre ne fait pas le lien. Ces trous ne sont pas des invitations à inventer. Ce sont les limites du fait public.

Ce que l’on peut tenir, c’est la consigne et son périmètre de versions. Ce que l’on peut tenir aussi, c’est la nature des correctifs déjà décrits dans le journal de septembre : plantage, mémoire, pénalité de fermeture. Le reste relève du suivi, pas de l’affirmation.

Après la mise à jour, le travail n’est pas fini

Installer le binaire ne dispense pas de regarder les canaux. Une fermeture déjà engagée sous l’ancienne version peut encore se jouer on-chain. Un pair qui tentait quelque chose avant la bascule peut réessayer. Les journaux des heures qui suivent le redémarrage valent autant que la note de version. Si un canal part en force sans raison claire, le moment est mauvais pour improviser.

Il est aussi utile de noter la version quelque part, avec la date. Lors de la prochaine alerte, la question ne sera plus « est-ce que j’ai mis à jour un jour », mais « est-ce que je suis au-delà de la borne citée ». Les opérateurs qui ont cru être couverts par la 26.06.7 viennent d’apprendre le prix de cette imprécision.

Enfin, la surveillance de la chaîne ne se délègue pas à l’espoir. Qu’il soit à jour ou en attente de migration, un nœud qui ne voit plus les blocs perd la moitié de sa défense. Lightning arbitre hors chaîne, mais il se défend on-chain. Couper les deux en même temps, par un arrêt total prolongé, n’est pas une mise en sécurité. C’est un autre risque, déjà souligné par le projet lors de la séquence d’août.

Ce qu’il faut retenir sans attendre la suite

Le 2 octobre 2026, Core Lightning a fait passer un message étroit, et c’est son étroitesse qui le rend actionnable. Les nœuds encore en 26.06.7 ou en deçà sont visés, selon des signalements reçus par l’équipe. La parade indiquée est la dernière livraison, pas un réglage, pas une attente. Le chemin d’attaque et le bilan des fonds restent non publics. Les correctifs de septembre, eux, montraient déjà que le pire cas connu incluait une perte lors d’une fermeture.

Le reste de l’été éclaire le décor, sans le remplacer : rapports d’intelligence artificielle triés en août, source retenu puis publié, examen de fonctions expérimentales mi-septembre, incidents distincts chez BTCPay et Zeus, vulnérabilité séparée chez Bitcoin Core. Aucun de ces fils ne donne le nom de la faille d’octobre. Tous rappellent que la maintenance n’est plus un geste annuel sur cette couche du réseau.

Pour qui fait tourner un nœud, la décision tient en une vérification. Si la version affichée est celle que l’alerte désigne, ou plus ancienne, le temps passé à chercher le détail manquant est du temps passé sur un logiciel déjà signalé comme cible. La mise à jour ne répond pas à toutes les questions. Elle retire, elle, le nœud du lot que l’équipe a explicitement pointé.