Deux mois après la publication par Lightning Labs, le 11 août, d’une série de failles de sécurité dans LND, 71 % des 550 nœuds publics du réseau Lightning qui tournaient alors sur une version exposée en utilisaient encore une, selon un preprint de Saurabh Kumar, de Bitcoin Data Labs, dont les données s’arrêtent au 13 octobre. Ces 71 % sont une part du groupe exposé, pas du réseau. Ces nœuds représentaient 14,9 % des nœuds LND actifs et détenaient 6,4 % de la capacité des canaux LND actifs.
Ce chiffre est l’inférence d’un seul chercheur à partir de données publiques, mise en ligne sur arXiv le 21 octobre et non relue par des pairs. Nous n’avons trouvé aucune mesure indépendante. Aucun vol lié à ces failles LND n’apparaît dans l’étude ni dans les avis de Lightning Labs.
En chiffres ronds, environ 390 des 550 nœuds n’ont pas bougé (calcul de notre rédaction à partir des pourcentages de l’étude). Environ 10 % de plus étaient passés à une ligne de versions plus récente, et 20 % ne comptaient plus comme actifs. Le total atteint 101 % parce que les parts sont arrondies. Les correctifs étaient anciens : LND 0.19.0-beta est sortie le 22 mai 2025, soit 446 jours avant la publication des avis.
Comment l’étude repère les nœuds LND exposés
LND est le logiciel qui fait tourner la plupart des nœuds publics de Lightning, la couche de paiement construite au-dessus du bitcoin (notre guide sur les réseaux de couche 1 et de couche 2 explique la différence). Le gossip de Lightning, c’est-à-dire les messages par lesquels les nœuds s’annoncent, ne contient aucune version logicielle. Impossible donc de compter les versions comme le font les robots d’exploration sur le réseau pair à pair de Bitcoin.
Le contournement de Kumar passe par les feature bits, les drapeaux que chaque nœud annonce. blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il a dressé la table des bits activés par chaque version de LND, Core Lightning (CLN), Eclair et LDK, puis l’a confrontée à 814 instantanés quotidiens du graphe public, pris par son propre nœud LND de mai 2023 jusqu’à la date limite du 13 octobre. Le résultat est une « ligne de versions » pour chaque nœud, qui peut couvrir plusieurs versions. Les versions correctives à l’intérieur d’une ligne restent invisibles.
Les 550 forment un groupe précis, présenté dans la figure 7 de l’étude : les nœuds LND actifs sur une ligne antérieure à 0.19 lors du dernier instantané avant la publication des avis. « Actif » signifie qu’un pair avait activé un canal vers le nœud et l’avait mis à jour au cours des 14 jours précédents. Les nœuds non annoncés, dont la plupart des portefeuilles mobiles, sont hors du compte. Il en va de même d’une flotte gérée de petits nœuds LND, qui a culminé à 1 781 nœuds actifs et a été exclue parce que ses nœuds bougent ensemble. L’inclure aurait ramené les 14,9 % à 12,9 %.
Vérifier la méthode est plus difficile pour LND que pour CLN. Certains nœuds CLN indiquent leur version dans leur alias, et la ligne inférée y était exacte pour 132 des 136 couples nœud-ligne. Aucun nœud LND de ses données ne le fait. Pour LND, l’étude s’appuie donc sur des tests indirects : les lignes ne reculent que dans 0,7 % des changements observés, et 97 % à 99,7 % des nœuds qui ont bougé juste après la livraison d’une nouvelle ligne LND par une plateforme se sont retrouvés sur la ligne livrée.
Kumar énumère lui-même les points faibles. Un nœud qui se met à jour sans redémarrer, ou dont la nouvelle annonce n’atteint jamais le nœud de l’auteur, garde ses anciens bits, ce qui pousse l’exposition à la hausse. Les opérateurs peuvent aussi désactiver des fonctions pour qu’une ligne récente paraisse plus ancienne. Les bornes strictes de l’étude pour le jour de la publication vont de 5 % à 15 % des nœuds LND actifs : les 5 % ne comptent que les nœuds dont toutes les lignes possibles sont touchées, si bien que les 14,9 % se situent en haut de cette fourchette. En sens inverse, 77 % des nœuds exposés avaient signé une annonce récente avec les anciens bits dans les 14 jours précédant la publication, donc la plupart n’étaient pas des entrées périmées.
Des failles allant du déni de service à la perte de fonds possible
L’index des avis de Lightning Labs recense dix avis LND datés du 11 août, trois classés T1 High et sept T3 Low. L’étude en regroupe six comme des dénis de service. Ce sont les éléments T3 corrigés dans la 0.19.0, où un pair peut épuiser les ressources d’un nœud ou perturber son gossip. Une autre faille corrigée dans la même version est d’une tout autre nature.
Il s’agit de l’échec du balayage de premier niveau des HTLC. Les HTLC sont les paiements conditionnels qui traversent les canaux Lightning. Sur LND 0.18, un nœud avec la réserve de portefeuille par défaut pouvait ne pas balayer sur la chaîne un HTLC sortant supérieur à environ 50 000 sats après une fermeture forcée. Un partenaire de canal pouvait faire transiter un gros HTLC par la victime, forcer la fermeture et en réclamer la valeur à l’expiration du délai. Lightning Labs évalue cette faille comme une perte de fonds par victime, et indique que la version non malveillante du bug a été observée en conditions réelles, avec des frais de balayage très élevés et des fermetures forcées en cascade. L’avis ne signale aucune attaque.
D’autres failles plus anciennes se situent derrière la même frontière 0.19. Le chercheur en sécurité Matt Morehouse a révélé le 4 décembre 2025 que LND 0.18.5 et les versions antérieures permettaient à des attaquants de voler les fonds d’un nœud par une faiblesse du sweeper. Deux autres avis T1 du lot d’août, l’exploit de destruction de frais par update_fee et le renvoi excessif d’échecs de HTLC, ont été corrigés dans la 0.18.3 et la 0.18.0, et seuls 4 % environ des nœuds LND actifs restaient sur les versions concernées à la date limite.
| Failles | Première publication | Corrigée dans | Nœuds LND actifs exposés lors de la publication (capacité) | Au 13 octobre (capacité) |
|---|---|---|---|---|
| Six dénis de service dans la gestion du gossip, des pairs et des files d’attente, classés T3 Low | 11 août 2026 | 0.19.0 | 15 % (6 %) | 13 % (6 %) |
| Échec du balayage de premier niveau des HTLC, classé T1 High, perte de fonds possible | 11 août 2026 | 0.19.0 | 10 % (5 %) | 8 % (6 %) |
| Blocage par remplacement et deux autres failles signalées par Matt Morehouse | 4 déc. 2025 | 0.19.0 | 28 % (12 %) | 13 % (6 %) |
| Renvoi excessif d’échecs de HTLC, classé T1 High | 4 mars 2025 | 0.18.0 | 20 % (8 %) | 4 % (0 %) |
| Manque de mémoire via les allocations d’écriture Brontide, classé T3 Low | 21 sept. 2026 | 0.20.0 | 22 % (11 %) | 20 % (10 %) |
| Trop peu de confirmations lors d’une fermeture coopérative | 13 août 2026 | 0.21.0 | 51 % (53 %) | 33 % (28 %) |
Source : preprint de Kumar, tableau III, classements de Lightning Labs. L’exposition compte les nœuds LND actifs sur une ligne touchée, flotte gérée exclue, chaque ligne à sa propre date de publication. Les deux dernières lignes montrent pourquoi la 0.19 n’est pas une ligne d’arrivée.
Combien de bitcoins sont exposés : on l’ignore
L’étude donne des parts pour les nœuds exposés, pas des montants, et nous ne les avons pas converties en dollars. Son principal chiffre de capacité est de 6,4 % de la capacité LND active le jour de la publication. À titre d’échelle seulement, elle chiffre toute la capacité LND active à 8 300 BTC le 7 décembre 2025, une date différente. Les nœuds exposés sont petits : leur part de capacité vaut environ la moitié de leur part en nombre de nœuds. Pour la seule faille de balayage avec perte de fonds, qui ne touche que la ligne 0.18, l’étude chiffre l’exposition à 10 % des nœuds LND actifs et 5 % de la capacité lors de la publication.
Un nœud sur une ligne touchée n’est pas automatiquement attaquable. « L’exposition n’est pas l’exploitabilité », écrit l’étude dans sa liste de limites. Plusieurs avis supposent un canal avec la victime, une configuration particulière ou des connexions entrantes. L’étude ne compte pas combien des 550 remplissent ces conditions. Kumar défend pourtant le point des petits nœuds par l’autre bout : la part de capacité est faible, écrit-il, « mais chacun détient les fonds de son opérateur ». Il ajoute que, lorsqu’une attaque exige un canal avec la victime, ces nœuds sont aussi les moins chers à atteindre.
Core Lightning est un autre sujet. Selon l’étude, les mainteneurs du projet ont signalé en octobre des attaques contre des nœuds CLN non corrigés. Cette affirmation est celle de l’étude, nous ne l’avons pas confirmée ailleurs, et elle concerne un autre logiciel : elle ne prouve en rien qu’un nœud LND ait été attaqué.
Rien de ce que nous avons lu ne relie ces failles LND aux vols dans les portefeuilles chauds BTCPay Server que nous avons rapportés plus tôt lundi, qui touchent des portefeuilles hébergés sur les propres serveurs BTCPay de commerçants.
Les nœuds Lightning se mettent à jour quand les plateformes livrent, pas quand les avis tombent
La conclusion la plus durable concerne le comportement. La moitié des nœuds LND restés sur une ancienne ligne sont passés à une nouvelle version en 88 jours. Le quart le plus petit par capacité a mis 135 jours en médiane, le quart le plus gros 75, et les nœuds déjà en retard de plus d’une ligne avaient environ cinq fois moins de chances de bouger une semaine donnée.
Les trois plus grandes vagues de mises à jour, de 262 à 385 nœuds chacune, sont survenues environ un jour après la publication d’une nouvelle version de LND dans la boutique d’applications d’Umbrel. Au moins 87 % de ces nœuds ont signé une nouvelle annonce dans les 48 heures suivant la fusion côté Umbrel, et les versions d’Umbrel arrivaient 19 à 41 jours après celles de LND. Depuis juin 2025, 17 % des mises à jour de LND sont tombées dans les 48 heures suivant une version de plateforme, des fenêtres qui couvrent 4,4 % du temps. Ce sont des minorants, car seuls Umbrel et BTCPay Server ont pu être datés, et le gossip ne dit pas sur quelle plateforme tourne un nœud.
Les avis ont eu bien moins d’effet. Le taux hebdomadaire de sortie des lignes touchées était de 1,4 % avant comme après le 11 août. L’étude est prudente sur ce point : une fois retirés les mouvements qui ont suivi la version de sécurité de BTCPay du 7 août, le rapport est de 1,30 avec un intervalle de confiance à 95 % de 0,56 à 3,03, donc un effet modeste ne peut pas être exclu. Sur les 12 publications qu’elle pouvait tester, dont neuf pour LND, seule celle de CLN du 19 juillet a nettement accéléré les mises à jour, et seulement chez les nœuds en retard d’une ligne.
L’explication la plus probable selon Kumar tient au calendrier. Le correctif du gossipd de CLN avait 90 jours lors de la publication, et l’exposition de CLN est ensuite tombée de 66,6 % des nœuds actifs à 24,2 % à la date limite, 46 % de ces nœuds s’étant mis à jour et 32 % n’étant plus actifs. Celui de LND avait 446 jours, de sorte que les nœuds restant à alerter étaient ceux qui avaient ignoré toutes les versions depuis. L’écart médian entre correctif et publication sur l’ensemble des avis étudiés est de 256 jours, un délai prévu pour laisser les opérateurs se mettre à jour avant que les attaquants ne sachent quoi chercher. Une cohorte antérieure raconte la même histoire : sur 1 284 nœuds LND exposés à la publication de Morehouse en décembre, 55 % étaient encore sur une ligne touchée quatre mois plus tard.
Que peuvent vérifier dès maintenant les opérateurs de nœuds LND
La plupart des portefeuilles Lightning mobiles étaient hors de cette étude, qui dit donc peu de chose de leurs utilisateurs. Quiconque fait tourner un nœud LND public peut lire la version directement sur la machine, ce qu’aucune inférence à partir du gossip ne peut égaler.
L’avis de Lightning Labs demande de passer à la v0.19.0-beta ou plus récente, ce qui supprime les sept failles corrigées dans cette version. C’est un plancher. Selon la politique de cycle de vie de l’entreprise, seules les deux lignes les plus récentes sont maintenues, actuellement 0.21 et 0.20. La ligne 0.19 est arrivée en fin de vie le 5 juin 2026, à la sortie de la 0.21.0, et ne reçoit plus de correctifs de sécurité. Des avis du 21 septembre mentionnent déjà des failles touchant la 0.19 avec des correctifs seulement dans la ligne 0.20 ou plus récente.
Les deux lignes maintenues ne sont pas identiques non plus. La faille de fermeture coopérative du tableau permet à une contrepartie de publier un engagement révoqué après une réorganisation d’un seul bloc, avec des fonds en danger, d’après la divulgation de Bastien Teinturier, qui ne connaît aucun utilisateur touché. Son message date le correctif de « 20.0 ». Les notes de version de LND le classent sous la 0.21.0, comme l’étude, et le code ajouté par ce changement est absent de l’étiquette v0.20.7 telle que nous l’avons lue le 2 novembre. Selon cette lecture, seule la ligne 0.21 en dispose.
Les dernières versions de LND, v0.21.6-beta et v0.20.7-beta du 30 octobre, désactivent aussi par défaut les écouteurs MPTCP contre la faille du noyau Linux CVE-2026-98432. Les notes de version parlent d’une mesure d’atténuation et précisent que le correctif du noyau est le seul remède. Elles demandent aux opérateurs Linux de désactiver aussi MPTCP sur la machine et d’installer un noyau corrigé dès que leur distribution en livre un ; Windows et macOS ne sont pas touchés. Les opérateurs sur Umbrel ou des boîtiers similaires reçoivent LND quand la plateforme le livre, donc la version de la boutique d’applications est celle à vérifier.
Les utilisateurs d’Eclair ont une tâche à part. La faille des requêtes de navigateur corrigée en octobre exigeait aussi qu’un opérateur agisse, et la version actuelle est désormais la v0.14.6 du 27 octobre, qu’ACINQ présente comme un renforcement de la sécurité et recommande d’installer.
Ce qui confirmerait ou fragiliserait les 71 %
L’auteur affirme que le code et les données agrégées sont publics, avec un script qui recalcule chaque chiffre, tandis que les instantanés quotidiens bruts sont disponibles sur demande. Une mesure indépendante depuis un second point d’observation, ou une relecture par des pairs, mettrait le chiffre à l’épreuve. Une déclaration de Lightning Labs ou d’Umbrel aiderait aussi : nous n’en avons trouvé aucune sur l’étude dans les sources consultées. Kumar ne publie que des agrégats, sans liste de nœuds individuels, car sa méthode identifie des nœuds qui font tourner des logiciels vulnérables.