Eclair : le correctif qui interdit à une page web de piloter un nœud Lightning

Mise à jour du 21 octobre 2026, 16 h 45 UTC : ACINQ a publié Eclair v0.14.5 le 20 octobre, cinq jours après la v0.14.4. 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 s’agit d’un nouveau correctif de durcissement de la sécurité, qui remercie pour leur divulgation responsable deux chercheurs signant Nuhiat-Arefin et mptfire, et ACINQ prévient que certains des problèmes « peuvent être exploités par des nœuds malveillants ». Les notes de version ne décrivent aucune des failles, ne donnent ni CVE ni liste des versions touchées, et aucune attaque ni perte n’a été signalée, comme l’a relevé CryptoSlate le 21 octobre. Les mainteneurs n’ont pas relié ces nouveaux correctifs au problème de navigateur décrit plus bas. Les opérateurs qui avaient déjà installé la v0.14.4 doivent donc mettre à jour une seconde fois. La procédure ne change pas : vérifier la signature et le fichier SHA256SUMS, arrêter Eclair, installer la v0.14.5 et redémarrer, sans fermer aucun canal.

ACINQ a publié Eclair v0.14.4, une version qui empêche une page web d’envoyer des commandes à un nœud Lightning Network par l’intermédiaire du navigateur de la personne qui l’exploite. Sortie le 15 octobre 2026 à 19 h 30 UTC, la mise à jour oblige l’API de contrôle du nœud à refuser toute requête qui porte un en-tête Origin, que les navigateurs ajoutent à chaque requête inter-sites et à toute requête autre qu’un simple GET ou HEAD. Jusqu’ici, selon les notes de version, n’importe quelle page web visitée par l’opérateur pouvait forger des appels d’API authentifiés sans jamais voir un mot de passe.

Aucun vol n’a été signalé. ACINQ n’a publié ni avis de sécurité ni numéro CVE pour ce problème, et CryptoSlate, qui a rapporté le changement le 17 octobre, ne donne aucun chiffre sur le nombre de nœuds exposés. Pour le petit cercle de ceux qui font tourner Eclair eux-mêmes, le correctif modifie pourtant la manière d’utiliser le logiciel, et les développeurs recommandent la mise à jour.

Sécurité d’un nœud Lightning : ce que change Eclair v0.14.4

Eclair est l’une des principales implémentations open source de Lightning, le réseau de paiement qui s’appuie sur le bitcoin. Il expose une API JSON sur un port local pour que son propriétaire consulte ses soldes, ouvre et ferme des canaux, envoie ou reçoive des paiements depuis des scripts ou avec l’outil en ligne de commande fourni, eclair-cli.

La nouvelle règle tient en une phrase des notes de version :

« L’API rejette désormais les requêtes qui portent un en-tête Origin, ce qui signifie qu’elle ne peut plus être utilisée depuis un navigateur web. » (notes de version d’Eclair v0.14.4)

Le travail qui la sous-tend est la pull request n° 3380, intitulée « Reject API access from browsers ». Elle a été rédigée par le développeur qui signe pm47, approuvée par sstone, puis ouverte et fusionnée le même jour, le 15 septembre 2026. Le correctif est donc resté un mois dans la branche principale d’Eclair avant d’arriver dans une version étiquetée. D’après la PR et son commit, toute requête avec un en-tête Origin reçoit désormais une erreur HTTP 403 avant même que la commande demandée ne s’exécute, et les en-têtes CORS, qui indiquaient aux navigateurs quels sites avaient le droit de parler à l’API, ont disparu. La modification touche six fichiers, avec 111 lignes ajoutées et 8 supprimées, et s’accompagne de tests pour une origine de navigateur avec et sans identifiants, pour les connexions websocket et pour la valeur spéciale Origin: null. Chaque appel refusé laisse aussi un avertissement dans le journal du nœud. La PR précise qu’elle corrige le signalement du projet Loupe et, par construction, tout autre signalement de CSRF visant un seul point d’accès.

Elle casse aussi quelque chose, volontairement. L’API ne peut plus du tout être appelée depuis un navigateur, même à partir d’une page servie par la même machine. Quiconque a construit un tableau de bord web qui parle directement à Eclair doit désormais placer un serveur à lui entre la page et le nœud. Les scripts, curl et eclair-cli ne sont pas touchés, puisqu’ils n’envoient pas cet en-tête.

Comment une page web pouvait atteindre votre nœud Lightning Network

L’attaque décrite dans les notes de version est ce que la PR appelle le CSRF de navigateur, pour « cross-site request forgery », soit une falsification de requête inter-sites. Le principe : le code d’un site fait exécuter à votre navigateur une action sur un autre service, en s’appuyant sur une session que votre navigateur détient déjà. L’attaquant n’a jamais besoin de votre mot de passe. C’est votre navigateur qui le fournit.

L’API d’Eclair utilise l’authentification HTTP basique, l’ancien système où le navigateur demande un mot de passe une fois puis s’en souvient. Les navigateurs joignent ces identifiants mis en cache aux requêtes suivantes, y compris à celles lancées par d’autres sites. Par ailleurs, les points d’accès de l’API acceptent des paramètres encodés comme un formulaire, de sorte qu’un simple formulaire HTML caché dans une page web suffit à fabriquer un appel valide. Les notes ajoutent le détail qui compte : la page attaquante ne peut pas lire la réponse, mais la commande a déjà été exécutée.

La chaîne ne fonctionne que si l’opérateur a, à un moment, ouvert l’API dans ce navigateur et enregistré l’identifiant. C’est le cas de ceux qui ont utilisé un outil dans le navigateur ou testé l’API à la main. CryptoSlate énumère les commandes accessibles par l’API : lire l’état du nœud, ouvrir et fermer des canaux, envoyer et recevoir des paiements. Les paiements figurant dans cette liste, un appel forgé pouvait en principe sortir de l’argent du nœud, qui garde ses fonds dans un hot wallet par construction. Ni ACINQ ni CryptoSlate ne documentent un cas où cela se serait produit.

Pourquoi limiter l’API à la boucle locale ne suffisait pas

On recommande aux opérateurs de garder l’API sur la boucle locale (« loopback »), l’adresse 127.0.0.1 que seul l’ordinateur lui-même peut joindre. Le conseil reste valable et il arrête les inconnus d’Internet. Il ne sert à rien contre le CSRF, car le navigateur qui transporte la requête forgée tourne sur ce même ordinateur. Du point de vue du nœud, l’appel vient d’un client local de confiance.

La PR précise qu’en vérifiant seulement la présence de l’en-tête, sans le comparer à une liste de sites autorisés, le correctif couvre aussi les requêtes envoyées avec Origin: null et le DNS rebinding. Cette technique consiste à faire croire au navigateur qu’un service installé sur votre propre machine fait partie du site de l’attaquant. Avec la nouvelle règle, le contenu de l’en-tête importe peu : s’il est là, la requête est refusée.

Faille Lightning Network : ni CVE, ni victime connue, plusieurs inconnues

La page des avis de sécurité d’ACINQ sur GitHub indiquait le 17 octobre qu’aucun n’était publié. Aucun identifiant CVE n’a été trouvé pour ce problème. La version attribue ses correctifs de durcissement « le plus souvent à @erickcestari et au projet Loupe », et l’entrée consacrée à l’en-tête Origin renvoie vers une fiche du suivi d’audit du projet Loupe, project-loupe/audit-eclair#223. C’est par ce canal que la découverte est parvenue aux développeurs ; les sources ne disent pas qui l’a personnellement signalée, ni quand.

Plusieurs questions restent ouvertes au 17 octobre :

1. Les versions exposées. Les notes décrivent une conception (authentification basique et points d’accès à paramètres de formulaire) qui semble antérieure à la v0.14.4, mais aucune source ne nomme une première version touchée.
2. Le fait que l’API soit activée par défaut, et avec quelle politique de mot de passe. Le projet demande aux opérateurs de ne pas la rendre joignable de l’extérieur, et les documents n’en disent pas plus.
3. Le nombre de nœuds dont l’API est configurée de façon à être atteinte par un navigateur, et si quelqu’un a tenté l’attaque. Rien n’a été signalé.
4. La question de savoir si une prime de bug bounty a été versée pour cette découverte.

Les développeurs sont clairs sur les limites de leur propre correctif. Dans la PR n° 3380, pm47 écrit : « Il s’agit d’une défense contre le CSRF des navigateurs, pas d’un mécanisme d’authentification. » Un programme qui n’est pas un navigateur peut simplement omettre l’en-tête. Le même texte ajoute que l’API « ne doit toujours jamais être exposée au-delà de la boucle locale », un point que CryptoSlate attribue aussi à pm47.

Un automne chargé en correctifs de sécurité pour Eclair

Le changement d’API n’est qu’un élément d’une liste plus longue. La même version regroupe des travaux de durcissement qui comptent, selon ACINQ, parce que « certains de ces problèmes peuvent être exploités par des nœuds malveillants ». Les entrées du journal des modifications, numérotées de #3387 à #3401, portent sur la validation de la longueur du fichier de graine, la protection contre un bitcoind malveillant en arrière-plan, les contrôles des scripts de fermeture envoyés par un partenaire de canal, une vérification de la longueur des paquets onion, ainsi que des corrections du splicing et du financement de canal « à la volée ». Pour les opérateurs, ce sont des raisons de mettre à jour en soi, qu’ils aient ou non déjà touché à l’API depuis un navigateur.

C’est aussi la quatrième version d’Eclair depuis la fin juillet. Plus tôt ce mois-ci, CryptoSlate (repris par KuCoin News le 2 octobre) a décrit un bogue d’épuisement de mémoire lié aux enregistrements de canaux non financés, présent dans la v0.14.0 et les précédentes et corrigé dans la v0.14.1 le 29 juillet. Lors d’un essai en laboratoire sur la v0.14.0, un tas mémoire de 4 Go s’est épuisé au bout d’environ 48 minutes, et comme les enregistrements restaient sur le disque, un redémarrage faisait replanter le nœud. Le chercheur Erick Cestari a publié les détails le 30 septembre, et la v0.14.3 était la version que les opérateurs devaient faire tourner. Le même rapport mentionnait un second bogue, LNF-2026-0003, trouvé par Matt Morehouse avec son outil lnfuzz, qui laissait des processus de canaux orphelins consommer de la mémoire jusqu’à une déconnexion ou un redémarrage.

Lightning a connu de plus grosses frayeurs. En octobre 2023, le développeur Antoine Riard a révélé le « replacement cycling », une attaque contre les nœuds de transfert qui touchait toutes les implémentations, Eclair compris, comme l’a rapporté Bitcoin Optech le 25 octobre 2023. Les implémentations ont livré des parades, comme une rediffusion plus fréquente et, chez Eclair et LND, une analyse du mempool, même si Matt Corallo, développeur de LDK, jugeait qu’elles n’étaient « pas censées régler ce problème ». Optech n’a signalé aucun usage de l’attaque dans la nature. Le problème de l’API d’Eclair est plus étroit : il suppose le navigateur de l’opérateur lui-même, un identifiant enregistré et une page malveillante visitée au mauvais moment.

Trois versions de sécurité d’Eclair en cinq semaines

Avec la v0.14.5, Eclair a sorti trois versions présentées comme du durcissement de sécurité en un peu plus de cinq semaines. La v0.14.3 est arrivée le 14 septembre avec des correctifs venus surtout du projet Loupe, la v0.14.4 le 15 octobre avec des correctifs venus surtout d’erickcestari et du projet Loupe, et la v0.14.5 le 20 octobre, qui crédite les deux nouveaux chercheurs. Les deux correctifs précédents de la branche 0.14, la v0.14.1 du 29 juillet et la v0.14.2 du 26 août, figurent sur la page des versions du projet comme des corrections de bogues.

Les trois versions de sécurité portent le même conseil d’ACINQ : mettre à jour. Pour un opérateur, le coût se résume à un redémarrage à chaque fois, puisque aucune n’impose de fermer des canaux. Ce qui change cette fois, c’est le peu d’informations. Le code de la v0.14.5 est public, mais ses notes n’expliquent pas ce qui a été corrigé, et ACINQ n’a pas dit quand il le ferait. La version ne concerne qu’Eclair : LND, Core Lightning et LDK publient leurs propres correctifs, à leur propre rythme.

Mise à jour d’Eclair : ce que les opérateurs doivent faire avant de redémarrer

La mise à jour est simple. ACINQ affirme que la v0.14.5, désormais la plus récente, est entièrement compatible avec les versions précédentes, comme l’était la v0.14.4, et qu’il n’est pas nécessaire de fermer les canaux : arrêter Eclair, installer la nouvelle version, le relancer. Les versions sont signées avec la clé E04E48E72C205463 et les compilations sont déterministes, ce qui permet de vérifier le binaire au regard du code source publié.

1. Vérifier la signature de la version téléchargée avec la clé de signature d’ACINQ avant de l’installer.
2. Arrêter Eclair, remplacer les binaires et redémarrer ; les canaux existants et les fonds restent en place.
3. Confirmer que l’API n’écoute toujours que sur 127.0.0.1 et que son mot de passe n’est utilisé nulle part ailleurs.
4. Si un tableau de bord de navigateur appelait directement l’API, déplacer ces appels derrière un petit serveur à soi, puisque la voie par le navigateur renvoie désormais 403.
5. Effacer du navigateur tout identifiant d’authentification basique enregistré pour l’API, qui n’a plus d’utilité.

Faire tourner un nœud Lightning, c’est garder des clés en ligne pour que le nœud puisse signer des paiements à tout moment. Cette contrepartie, expliquée dans notre guide sur le fonctionnement des portefeuilles crypto, explique pourquoi une API locale capable de dépenser mérite autant de soin que la phrase de récupération elle-même.

Qui est concerné par la mise à jour d’Eclair

Le changement concerne les personnes qui font tourner Eclair comme un serveur et se servent de son API JSON : exploitants de nœuds de routage, commerçants ou développeurs qui ont bâti leur propre installation dessus. Eclair est une implémentation minoritaire en nombre de nœuds, mais son éditeur pèse sur le réseau : ACINQ exploite l’un des plus gros nœuds de routage et édite le portefeuille mobile Phoenix.

Le problème porte sur l’API de l’opérateur, pas sur les applications de portefeuille mobiles. ACINQ n’a publié aucune déclaration sur Phoenix, et rien dans les notes de version n’indique que ses utilisateurs doivent agir. Ceux qui paient en Lightning via une application custodiale ou une autre implémentation n’ont rien à faire ici. Les lecteurs qui découvrent les réseaux de seconde couche peuvent commencer par notre entrée de glossaire sur les layer 2.

La suite pour les opérateurs de nœuds Eclair

Aucune date n’est fixée pour la suite. La fiche audit-eclair#223 pourrait donner lieu à un compte rendu plus complet du projet Loupe une fois la divulgation terminée ; aucun calendrier n’a été donné. ACINQ n’a pas dit quand il décrirait les failles corrigées dans la v0.14.5. La version à installer est désormais la v0.14.5, disponible sur GitHub depuis le 20 octobre, qui remplace la v0.14.4 comme version recommandée par ACINQ.