Alerte Urgente Sur Core Lightning : Les Vieux Nœuds Sont Visés

Imaginez un commerçant qui encaisse des paiements en satoshis depuis des mois, convaincu que son nœud tourne tout seul dans un coin du bureau. Un matin, le canal se ferme mal, une pénalité s’abat, et une partie des fonds disparaît sans qu’aucune alerte claire n’ait précédé le choc. Ce scénario n’est plus une hypothèse d’école. Le 2 octobre 2026, l’équipe de Core Lightning a publié un avertissement sec : des attaquants ciblent activement les installations encore figées sur la version 26.06.7 ou sur n’importe quelle mouture antérieure. La consigne tient en une phrase, et elle ne laisse pas de place à la procrastination.

L’alerte arrive quelques semaines seulement après une série de correctifs de sécurité. Elle ne dit pas quel trou est exploité. Elle ne dit pas si des satoshis ont déjà changé de mains. Elle dit simplement que des rapports d’attaques circulent, et que rester sur une vieille version revient à laisser la porte entrouverte. Pour qui fait tourner un nœud, route des paiements ou garde des canaux ouverts avec des pairs, la question n’est plus de savoir si la mise à jour peut attendre le week-end. Elle est de savoir combien de temps le logiciel actuel peut encore tenir.

Ce que l’alerte change vraiment pour les opérateurs

Jusqu’ici, les bulletins de Core Lightning ressemblaient à une routine de maintenance un peu tendue. Depuis août, les développeurs enchaînent les réponses à un flot de signalements, dont une part non négligeable est née de modèles d’intelligence artificielle passés au peigne fin sur le code ouvert. Plusieurs failles ont été confirmées. D’autres rapports se sont révélés creux. Le travail de tri a été long, parfois frustrant, toujours nécessaire.

La bascule du 2 octobre est d’une autre nature. Ce n’est plus seulement une invitation à installer un correctif avant qu’un curieux ne reconstitue la faille à partir du diff public. C’est la mention, rare et lourde, de rapports d’attaques en cours contre des nœuds non patchés. Le projet n’a pas publié de preuve, de hash de transaction, ni de récit d’incident nommé. Il a toutefois cessé de dire, comme en août, qu’aucune exploitation active n’était connue.

Mise à jour de sécurité urgente : si vous exécutez la version 26.06.7 ou une version antérieure, passez à la dernière version dès que possible.

Cette formule, reprise par l’équipe, est volontairement nue. Pas de numéro de CVE brandi en une. Pas de score CVSS. Pas de mode d’emploi de l’attaque. L’absence de détail n’est pas un oubli de communication. C’est une stratégie déjà utilisée en septembre : retarder la carte précise du trou le temps que les opérateurs bougent. Le revers, c’est que l’opérateur lambda ne sait pas s’il est exposé à un plantage, à une saturation mémoire, ou à une perte sèche lors d’une fermeture de canal.

Pourquoi le silence sur la faille n’est pas rassurant

Dans un logiciel de paiement, le flou a un coût psychologique autant que technique. Un plantage de nœud se répare. Une fuite mémoire se contient. Une pénalité de fermeture, elle, se paie en bitcoins déjà engagés dans le canal. L’opérateur qui lit l’alerte sans savoir laquelle de ces issues est en jeu a tendance à sous-estimer la plus grave, parce qu’elle est aussi la moins fréquente dans l’imaginaire collectif.

Or les notes de la version 26.06.8, publiée le 22 septembre, décrivent précisément ce spectre. Un correctif visait un bug capable de faire tomber le nœud de l’expéditeur. Un autre bloquait des requêtes capables d’épuiser la mémoire via l’interface REST. Un troisième, plus sensible, concernait la fermeture de canal : dans certaines conditions, l’utilisateur pouvait perdre des fonds au profit d’une pénalité. Rien n’indique que l’attaque signalée en octobre exploite l’un de ces trois points plutôt qu’un quatrième, encore non nommé. Rien n’indique non plus le contraire.

Cette incertitude force une lecture prudente. Tant que le projet n’a pas dit quel vecteur est visé, la seule hypothèse raisonnable est que toutes les failles corrigées depuis août restent des candidats, et que des versions antérieures à 26.06.7 cumulent en plus les trous plus anciens. Un nœud resté sur une branche de l’été n’a donc pas un seul retard. Il en a plusieurs, empilés.

Le calendrier qui mène à l’alerte d’octobre

Pour comprendre pourquoi l’avertissement tombe maintenant, il faut remonter le fil, sans le romantiser. En août, les mainteneurs ont confirmé plusieurs vulnérabilités après avoir épluché une vague de rapports, souvent produits ou accélérés par des outils d’analyse automatique. La version 26.06.7 est sortie le 28 août pour colmater ce lot. Son code source a été retenu environ deux semaines, le temps de laisser les opérateurs installer le binaire avant que des lecteurs patients ne remontent des correctifs vers les failles.

Pendant cette fenêtre, une option d’attente existait : lancer le démon en mode hors ligne. Le nœud se coupait de ses pairs Lightning, cessait d’envoyer, de recevoir et de router, mais continuait à surveiller la chaîne Bitcoin. Ce compromis n’était pas une solution. C’était un garde-fou pour ne pas arrêter complètement le processus, car un démon éteint ne voit plus les transactions liées aux canaux.

Mi-septembre, un second front s’est ouvert. Le 16, l’équipe a indiqué enquêter sur un problème potentiel lié à des fonctions expérimentales, avec un risque possible sur les fonds. Le 22, la 26.06.8 est arrivée, créditant le Bitcoin Red Team, douze chercheurs ou groupes nommés, et des rapporteurs anonymes. Pas de période d’embargo cette fois, mais quelques tests gardés privés, toujours pour compliquer la rétro-ingénierie. Puis, début octobre, les rapports d’attaques contre les versions non mises à jour.

Ce que la 26.06.8 a réellement colmaté

Lire un changelog de sécurité, c’est accepter de ne voir que la surface. Les mainteneurs décrivent l’effet, rarement la recette. Trois effets, toutefois, suffisent à cadrer le danger pour un opérateur non spécialiste.

Le premier est un déni de service ciblé sur l’envoyeur. Un pair malveillant, ou un message forgé, pouvait faire s’effondrer le processus. Sur Lightning, un nœud à terre ne route plus, ne surveille plus ses engagements avec la même réactivité, et laisse à l’autre bout du canal une fenêtre pour jouer avec les délais. Ce n’est pas toujours une perte directe. C’est souvent le début d’une mauvaise séquence.

Le deuxième passe par l’interface REST. Des requêtes pouvaient consommer la mémoire disponible jusqu’à rendre la machine inutilisable. Un nœud domestique, un VPS modeste, une box recyclée : tous partagent la même faiblesse face à une saturation. L’attaquant n’a pas besoin d’être élégant. Il a besoin d’être persistant.

Le troisième est le seul qui parle explicitement d’argent. Lors d’une fermeture, dans un enchaînement précis de conditions, l’utilisateur pouvait se retrouver du mauvais côté d’une pénalité. Sur Lightning, la pénalité existe pour punir la publication d’un ancien état de canal. Quand un bug interne pousse le logiciel honnête à se comporter comme s’il trichait, la sanction tombe quand même. C’est le genre de faille que les opérateurs redoutent plus qu’un simple crash, parce qu’elle transforme une règle de sécurité du protocole en piège contre celui qui l’applique.

Versions concernées, et celles qui ne le sont pas

Le message est binaire. Toute installation en 26.06.7 ou en deçà est dans le viseur annoncé. La marche à suivre est de passer à la dernière version disponible, pas de sauter une marche intermédiaire en espérant que le correctif de septembre suffise si l’on est encore plus en retard. Un nœud en 26.06.6, en 26.06.5, ou sur une branche plus ancienne, cumule les retards d’août et de septembre.

À l’inverse, rien dans l’alerte ne désigne les installations déjà alignées sur la dernière livraison comme cibles de cette campagne. Cela ne signifie pas qu’elles sont invulnérables pour l’éternité. Cela signifie que le signal du jour porte sur le stock non patché. Les opérateurs qui ont installé la 26.06.8 dans les jours suivant le 22 septembre sont, sur ce point précis, du bon côté de la ligne. Ceux qui ont noté le bulletin et l’ont laissé dans un onglet ne le sont pas.

Situation du nœud	Lecture de l’alerte	Geste utile
Version 26.06.7 ou plus ancienne	Explicitement visée par les rapports d’attaques	Mettre à jour sans attendre
Déjà sur la dernière livraison	Hors du périmètre annoncé ce jour	Vérifier la version réelle, pas le souvenir
Impossible de patcher tout de suite	Exposition maintenue	Mode hors ligne temporaire, démon toujours actif
Démon complètement arrêté	Plus d’attaque Lightning, mais plus de veille chaîne	À éviter si des canaux sont encore ouverts

Le mode hors ligne, pis-aller et non refuge

Lors de la séquence d’août, les mainteneurs avaient déjà décrit une sortie de secours. Couper les pairs, geler les paiements, garder le démon en vie pour suivre Bitcoin. Cette option revient dans la tête des opérateurs dès qu’une mise à jour coince : dépendance système, paquet absent, fenêtre de maintenance refusée par un hébergeur, peur de casser une config maison.

Elle reste préférable à l’immobilisme, mais elle n’efface pas le logiciel vulnérable. Elle réduit la surface en coupant le dialogue Lightning. Elle ne réécrit pas le binaire. Dès que les pairs sont reconnectés sans correctif, l’exposition revient. Et un nœud hors ligne longtemps devient, pour ses contreparties, un pair silencieux dont les canaux finiront par être fermés unilatéralement, parfois dans de mauvaises conditions de frais ou de timing.

Arrêter complètement le processus est pire encore tant que des canaux existent. Sans veille de la chaîne, l’opérateur ne voit pas une transaction de clôture publiée par l’autre bout. Le protocole Lightning repose sur cette vigilance. Un bug logiciel est une menace. Une absence de surveillance en est une autre, plus ancienne, et tout aussi capable de coûter des fonds.

Ce que l’on ne sait toujours pas

Trois inconnues dominent la lecture honnête de l’alerte. La première : quelle vulnérabilité est réellement visée. La deuxième : si une attaque a abouti. La troisième : si des fonds ont été perdus. Le projet a choisi de ne pas trancher ces points en public. Il faut donc résister à deux tentations symétriques. La première consiste à conclure que « rien n’a été volé, sinon on l’aurait dit ». La seconde consiste à inventer un casse spectaculaire à partir d’une phrase de trois lignes.

Entre les deux, il reste un fait opérationnel. Des acteurs assez motivés pour sonder des nœuds anciens existent, et ils le font maintenant, pas dans un exercice de laboratoire daté. Pour un réseau dont la promesse est le paiement rapide et la garde personnelle, cette nuance change la température. Lightning n’a pas « été cassé ». Une implémentation précise, dans des versions précises, est sous pression. C’est déjà assez pour bouger.

L’ombre des rapports générés par l’intelligence artificielle

Le contexte d’août éclaire octobre sans l’excuser. Des modèles de plus en plus capables ont été braqués sur le code ouvert, produisant un volume de signalements que les petites équipes peinent à absorber. Une partie de ces rapports ne tient pas. Une autre partie, après vérification humaine, tient. Le tri devient lui-même un goulot. Pendant que les mainteneurs valident, le code vulnérable continue de tourner chez ceux qui n’ont pas encore la nouvelle version.

Ce phénomène n’est pas propre à Core Lightning. Il touche tout projet public dont le dépôt est lisible. L’effet de bord est double. D’un côté, des failles réelles remontent plus vite. De l’autre, le bruit noie le signal, et la fenêtre entre la découverte et le correctif installé s’allonge si les opérateurs attendent une confirmation parfaite. L’alerte d’octobre suggère que cette fenêtre a été utilisée.

Il serait facile d’en faire un réquisitoire contre l’analyse automatique. Ce serait manquer la moitié du tableau. Les correctifs de septembre créditent des chercheurs humains, un red team, des anonymes. L’outillage accélère la découverte. La responsabilité de livrer, d’embargoer ou non, et d’installer, reste humaine. Un nœud non mis à jour n’est pas la victime d’un modèle. Il est le résultat d’un délai.

Embargo, tests cachés, course contre la rétro-ingénierie

Deux tactiques ont été employées en quelques semaines. En août, retenir le code source deux semaines après la 26.06.7. En septembre, publier la 26.06.8 sans embargo global, mais garder privés quelques tests. L’idée est la même : ne pas offrir, clé en main, la carte du bug à qui sait lire un diff.

Cette pratique divise toujours. Les partisans de la transparence totale estiment qu’un correctif public est le seul moyen pour l’écosystème de vérifier, de porter le patch ailleurs, de ne pas dépendre d’une équipe. Les partisans de l’embargo court répondent qu’un diff trop bavard, publié alors que la majorité des nœuds n’a pas bougé, équivaut à un mode d’emploi. Les deux arguments tiennent. L’alerte d’octobre montre surtout que la course n’est pas théorique. Quelqu’un, quelque part, teste déjà les anciennes versions.

Pour l’opérateur, le débat d’école importe moins que le geste. Installer. Vérifier le numéro de version affiché, pas celui noté dans un fichier de suivi. Redémarrer proprement. Contrôler que les canaux remontent. Puis seulement commenter la politique de divulgation.

D’autres secousses dans l’écosystème Lightning en 2026

L’avertissement sur Core Lightning ne tombe pas dans un désert. Août a aussi vu un exploit actif viser des installations BTCPay Server non passées en 2.4.2. La faille exposait des macarons d’administration LND. Un macaron d’administrateur ouvre des droits étendus sur le portefeuille Lightning associé. Des fonds ont été drainés sur certains nœuds touchés. Une prime de récupération de 10 pour cent a ensuite été soutenue, plafonnée à 3 bitcoins si l’ensemble des actifs volés revenait. Les versions antérieures à 2.4.2 étaient concernées, y compris des candidates. 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’incident a été contenu en quelques heures, les services sont restés offline le temps d’un audit, et l’équipe a indiqué que les fonds clients n’avaient ni été perdus ni été mis en risque. L’enquête n’avait pas identifié de vulnérabilité dans le logiciel de nœud Lightning. Les utilisateurs dont les canaux de fournisseur de service avaient été fermés se sont vu promettre des canaux de remplacement.

Ces deux épisodes ne se confondent pas avec l’alerte d’octobre. L’un concerne un empilement autour de LND et d’un serveur de paiement. L’autre concerne une infrastructure d’éditeur, pas une faille de nœud confirmée. Ils rappellent toutefois une évidence que les slogans sur « Lightning, c’est juste Bitcoin » ont tendance à lisser : la surface réelle est un empilement de logiciels, de macarons, d’interfaces, d’hébergeurs. Un correctif sur un maillon ne protège pas le maillon d’à côté.

Le rappel venu de Bitcoin Core

La chaîne elle-même n’a pas été épargnée par les bulletins. En mai, une vulnérabilité de haute sévérité a été rendue publique, pouvant permettre à un mineur de faire planter à distance des nœuds Bitcoin vulnérables. Le défaut, suivi sous l’identifiant CVE-2024-52911, touchait les versions postérieures à 0.14.0 et antérieures à 29.0. Le correctif était déjà dans Bitcoin Core 29.0 avant la divulgation.

Le mécanisme passait par l’interpréteur de script au moment de la validation d’un bloc. Un bloc invalide fabriqué 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. Coûteux, donc. 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 Lightning est instructif sans être identique. Sur la couche de base, l’exploitation demande une dépense réelle en travail. Sur un nœud Lightning exposé à ses pairs, le coût d’une sonde peut être bien plus bas. C’est précisément pour cela qu’une alerte « des attaquants ciblent les anciennes versions » pèse plus lourd qu’un bulletin théorique. Le ticket d’entrée n’est pas une ferme de minage. C’est une connexion.

Qui est vraiment exposé, au-delà du numéro de version

Tous les nœuds anciens ne présentent pas le même profil de risque. Un démon chez soi, sans port ouvert, avec une poignée de pairs de confiance, n’offre pas la même cible qu’un routeur public, bien annoncé, avec une interface REST joignable. L’alerte ne fait pas cette distinction. Elle a raison de ne pas la faire : les opérateurs surestiment souvent l’isolement de leur machine.

Un pair suffit. Un canal suffit. Une API laissée sur une adresse interne mais joignable via un tunnel suffit. Les notes de septembre mentionnent explicitement l’interface REST comme vecteur d’épuisement mémoire. Quiconque a activé cette interface pour un tableau de bord, un script de surveillance ou un outil tiers doit la compter dans la surface, pas comme un détail d’admin.

Les fonctions expérimentales, évoquées le 16 septembre, ajoutent une couche. Activer une option marquée comme instable pour gagner un peu de confort, puis oublier de suivre les bulletins, est un classique. Le confort d’hier devient le vecteur d’aujourd’hui. Si votre configuration active des modules hors du chemin par défaut, la mise à jour ne se limite pas au binaire. Elle inclut la relecture de ce que vous avez allumé.

Une méthode simple pour ne pas se tromper de version

La plupart des retards ne viennent pas d’un refus. Ils viennent d’une confusion. Le paquet du système dit une chose, le binaire lancé par un service systemd en dit une autre, un conteneur ancien continue de tourner à côté du conteneur neuf. Avant de se rassurer, il faut interroger le processus qui écoute vraiment.

Notez le numéro exact. Comparez-le à 26.06.7. Si vous êtes égal ou en dessous, vous êtes dans le périmètre de l’alerte. Si vous êtes au-dessus, confirmez qu’il s’agit bien de la dernière livraison annoncée, pas d’un intermédiaire oublié. Redémarrez après installation. Vérifiez à nouveau. Un service qui n’a pas rechargé l’unité continue d’exposer l’ancien code avec un faux sentiment de sécurité.

Gardez une copie de la configuration et une note des canaux avant l’opération. Une mise à jour de nœud Lightning n’est pas un redémarrage de blog. Elle touche un logiciel qui détient des états financiers. La prudence n’est pas de retarder. Elle est de préparer, puis d’exécuter vite.

Ce que risque concrètement un canal mal fermé

Pour sortir du jargon, revenons au canal. Deux parties verrouillent des bitcoins dans une sortie partagée. Elles s’échangent des états successifs, chacun annulé par le suivant. Publier un vieil état est puni : la contrepartie peut réclamer les fonds via une transaction de pénalité. Le mécanisme protège contre la triche. Il suppose que le logiciel honnête ne publie pas, par bug, un état qu’il devrait considérer comme révoqué, ou qu’il ne rate pas la fenêtre pour réagir.

Le correctif de septembre sur la fermeture dit exactement cela : dans certaines conditions, l’utilisateur pouvait perdre des fonds au profit d’une pénalité. Pas besoin d’imaginer un voleur romanesque. Il suffit d’un enchaînement où le nœud se comporte mal au moment où le canal se ferme, et où les règles du protocole, elles, se comportent bien. La sanction tombe sur le bogue, pas sur l’intention.

C’est pourquoi l’alerte d’octobre, même muette sur le vecteur, doit être lue avec ce scénario en tête. Un crash se voit. Une mémoire saturée se voit. Une pénalité, elle, se constate sur la chaîne, souvent trop tard pour négocier. Les opérateurs qui routent pour des tiers, ou qui tiennent des canaux commerciaux, ont en plus un devoir de délai court : leurs pairs ne patienteront pas le temps d’un week-end de lecture.

Routage, liquidité, et effet domino discret

Un nœud isolé qui tombe gêne son propriétaire. Un nœud de routage qui tombe, ou qui se met hors ligne par précaution, retire de la liquidité à des chemins de paiement. Si une fraction notable du réseau traîne sur de vieilles versions et se déconnecte en même temps après une alerte, les chemins se rallongent, les frais montent, des paiements échouent sans que la chaîne Bitcoin, elle, ait bougé d’un satoshi.

Ce n’est pas un effondrement. C’est une dégradation. Lightning a déjà connu des épisodes où la disponibilité des pairs comptait plus que le cours. L’incitation correcte, pour le réseau comme pour chacun, est de patcher et de rester en ligne, pas de couper en masse. Le mode hors ligne est un sas individuel. Il ne doit pas devenir une mode collective.

Les services qui empilent Core Lightning derrière une caisse, un pourboire, un distributeur ou une place de marché interne ont un intérêt supplémentaire à documenter leur version. Leurs utilisateurs ne lisent pas les dépôts de code. Ils voient un paiement qui passe ou qui ne passe pas. La responsabilité de la mise à jour est chez l’opérateur, pas chez le client qui scanne un QR code.

Comment parler de l’alerte sans semer la panique inutile

Il y a une façon fausse de raconter cette histoire : « Lightning est piraté, sortez vos fonds ». Elle ignore que l’avertissement vise des versions, pas le protocole dans son ensemble, et qu’aucune perte chiffrée n’a été publiée. Il y a une façon tout aussi fausse : « simple maintenance, circulez ». Elle ignore que le projet parle d’attaquants, pas seulement de correctifs préventifs.

La formulation juste tient en peu de mots. Une implémentation majeure a des trous corrigés. Des personnes testent les nœuds qui n’ont pas installé les trous corrigés. Le projet ne confirme ni le succès ni l’échec de ces tests. La réponse proportionnée est la mise à jour, pas la fermeture générale des canaux, pas non plus l’attente d’un article plus détaillé.

Les communautés d’opérateurs ont ici un rôle prosaïque. Relayer le numéro de version, pas la rumeur. Aider à distinguer le binaire lancé du paquet installé. Rappeler que le mode hors ligne garde le démon éveillé. Éviter les captures d’écran de configurations sensibles. Une alerte de sécurité attire aussi les curieux maladroits et les opportunistes. Le canal de discussion n’a pas à devenir un mode d’emploi.

Ce que les semaines d’août enseignent encore

Quand la 26.06.7 est sortie, aucune preuve publique n’établissait une exploitation réussie ni des pertes via les failles alors confirmées. C’était rassurant, et incomplet. L’absence de preuve n’est pas la preuve d’absence, surtout sur un réseau où les victimes n’ont pas toujours intérêt à détailler leur setup. Octobre modifie au moins le premier terme : des ciblages sont signalés. Le second terme, les pertes, reste non documenté.

Cette progression, de « failles confirmées » à « attaques signalées », est le rythme normal d’un logiciel exposé. Le correctif précède parfois l’abus. Parfois l’abus précède le correctif. Ici, le correctif a plusieurs semaines d’avance sur l’alerte d’abus. Ceux qui ont bougé en septembre ont utilisé cette avance. Ceux qui n’ont pas bougé la consomment maintenant.

Il est tentant de blâmer les petits opérateurs, les Raspberry oubliés, les tutoriels de 2024 encore en favori. Une partie du retard vient de là. Une autre vient de la friction : compilation, dépendances, peur de casser un service qui rapporte quelques milliers de satoshis par jour. La friction n’annule pas le risque. Elle explique seulement pourquoi l’alerte trouve encore des cibles.

Garder le démon vivant, surveiller la chaîne

Un point technique mérite d’être répété, parce qu’il contredit l’instinct. Face à une faille, l’instinct dit d’éteindre. Sur Lightning, éteindre un nœud qui a des canaux ouverts, c’est devenir aveugle aux transactions de clôture. Le conseil donné en août reste valable comme mesure d’attente : rester démarré, se couper des pairs, continuer à regarder Bitcoin.

Cette veille ne remplace pas le correctif. Elle évite d’ajouter une faute d’inattention à une faute de version. Dès que le paquet est prêt, on repasse en ligne sur le logiciel à jour. Laisser un nœud en hors-ligne des jours durant, « en attendant d’y voir plus clair », expose à des fermetures forcées par les pairs, avec des frais de chaîne que personne ne contrôlera à votre place.

Si vous tenez plusieurs nœuds, traitez-les un par un, en notant l’état des canaux avant et après. Un inventaire de dix minutes évite l’erreur classique : mettre à jour la machine de test et croire que la machine de production a suivi. Les attaquants, eux, ne feront pas cette confusion.

Le rôle des chercheurs et du red team

Les notes de la 26.06.8 nomment le Bitcoin Red Team et douze chercheurs ou collectifs, plus des anonymes. Ce crédit n’est pas une décoration. Il rappelle que la sécurité de ce logiciel dépend d’un cercle plus large que l’équipe coeur, et que ce cercle a choisi la divulgation responsable plutôt que la publication immédiate des détails.

La contrepartie de cette responsabilité, c’est la vitesse d’installation. Un rapport bien fait ne protège personne tant que le binaire ancien répond encore sur le réseau. Les chercheurs ont fait leur part en août et en septembre. La part restante est distribuée, machine par machine. C’est moins glorieux qu’un avis de sécurité. C’est ce qui décide si l’avis a servi.

Les opérateurs qui trouvent eux-mêmes un comportement bizarre ont intérêt à le remonter par les canaux prévus, sans poster la recette. L’alerte du jour montre que des yeux hostiles lisent aussi. Ajouter un tutoriel d’exploitation dans un fil public, même « pour prévenir », raccourcit le travail de ceux que l’on prétend gêner.

Au-delà de Core Lightning : une hygiène de versions

L’épisode BTCPay d’août et l’épisode Zeus montrent que le voisinage logiciel compte autant que le démon. Un macaron d’administration qui fuite, une infrastructure d’éditeur coupée, un nœud ancien : trois histoires, trois leçons. Ne pas exposer les secrets d’admin. Ne pas confondre panne d’hébergeur et faille de protocole. Ne pas laisser un numéro de version prendre la poussière.

Une hygiène minimale tient sur une page. Savoir quel logiciel parle à quel portefeuille. Savoir quelle version tourne. Savoir qui peut joindre l’API. Savoir comment couper les pairs sans tuer la veille chaîne. Savoir où est la dernière annonce de l’équipe, et la lire avant les commentaires. Rien de tout cela ne demande d’être développeur. Tout cela demande de traiter un nœud comme un coffre, pas comme une appli qu’on oublie après l’installation.

Les portefeuilles grand public qui ouvrent des canaux pour l’utilisateur héritent de la même logique, même si l’utilisateur ne voit pas le démon. Quand l’éditeur met à jour, le risque baisse. Quand l’éditeur tarde, le risque se concentre. L’alerte d’octobre parle aux opérateurs de Core Lightning. Elle parle aussi, en creux, à tous ceux qui délèguent cette couche sans demander le numéro de version.

Ce qu’il faut retenir avant de refermer l’onglet

Le 2 octobre 2026, l’équipe demande une montée de version immédiate pour tout nœud en 26.06.7 ou avant, parce que des attaques contre ces installations ont été signalées. Le vecteur n’est pas nommé. Le succès des attaques n’est pas confirmé. Les pertes ne sont pas chiffrées. Les correctifs disponibles depuis le 22 septembre couvrent notamment un crash d’envoyeur, un épuisement mémoire via REST, et un risque de pénalité à la fermeture. Rester en dessous, c’est accepter de ne pas savoir lequel de ces risques, ou un autre, est en train d’être testé.

La bonne séquence est courte. Vérifier la version réelle. Installer la dernière livraison. Garder le démon actif si l’installation doit attendre quelques heures, en coupant les pairs. Ne pas éteindre un nœud qui a encore des canaux. Ne pas extrapoler un vol massif que personne n’a documenté. Ne pas non plus attendre un second avertissement plus bavard. Le premier a déjà le mérite d’être clair sur l’action, sinon sur la méthode.

Lightning reste un empilement jeune, utile, et exposé. Ses règles de pénalité protègent contre la triche et punissent aussi les bugs. Ses implémentations reçoivent, en 2026, à la fois plus de rapports et plus de regards hostiles. Dans ce décor, la version du logiciel n’est pas une note de bas de page. C’est la ligne qui sépare un nœud surveillé d’un nœud sondé. Ce matin, cette ligne passe par 26.06.7. En dessous, on est du mauvais côté.