LNbits demande à tous les opérateurs d’éteindre leurs serveurs Lightning face à une vague d’attaques
Le 8 novembre 2026, le projet LNbits a demandé à tous les opérateurs de son portefeuille Lightning auto-hébergé de couper leurs serveurs, après qu’un exploit a vidé 2 285 545 satoshis chez un opérateur avant la diffusion d’un correctif. Si vous auto-hébergez LNbits, éteignez l’instance exposée et désactivez les extensions jusqu’à la sortie des patchs.
8 novembre 2026. Le projet LNbits demande à tous les opérateurs de son portefeuille Lightning auto-hébergé d’éteindre leurs serveurs, face à une vague d’attaques. 12 h 33 UTC. Un premier avertissement, plus étroit, demandait seulement de désactiver l’extension Paywall. 9 novembre 2026, 09 h 00 UTC. Aucune version corrigée n’avait encore été publiée. Pourquoi c’est important : auto-héberger un portefeuille Bitcoin inverse le modèle de confiance — et quand une faille frappe, l’avis de mise hors service devient, à lui seul, l’intégralité du plan de réponse à incident.
Un exploit qui a vidé 2 285 545 satoshis avant le correctif
LNbits est un portefeuille Lightning Network libre et open source que l’on installe sur sa propre machine ou son serveur. Là où la plupart des portefeuilles confient les fonds à un dépositaire, LNbits remet la garde au propriétaire : c’est lui qui détient les clés, c’est lui qui exploite le nœud, c’est lui qui assume la sécurité. C’est exactement la promesse du self-hosted appliquée à l’argent — et la raison pour laquelle un incident de ce type ne se corrige pas par une mise à jour distante poussée par un fournisseur.
L’attaque n’est pas une hypothèse. Kevin Ravensberg, l’opérateur du bot Telegram BitTipBot, a déclaré que son serveur avait été exploité avant l’avis de mise hors service. Des comptes fraîchement créés ont utilisé un exploit pour retirer 2 285 545 satoshis — environ 0,023 bitcoin — avant qu’il ne puisse l’arrêter. L’attaque s’est déroulée de 09 h 22 à 14 h 00 UTC le 8 novembre, soit plus de trois heures avant le premier avertissement du projet, diffusé à 12 h 33 UTC.
Ravensberg s’est engagé à rembourser les utilisateurs de BitTipBot, dont les fonds restent inaccessibles tant que les failles ne sont pas corrigées. Dans un message ultérieur, il a précisé que le développeur Ben Arc et une équipe de testeurs avaient confirmé « quelle extension exacte a été utilisée » pour l’exploit — mais ni lui ni le projet n’ont nommé cette extension publiquement à la date du 9 novembre à 09 h 00 UTC.
Une chronologie serrée : deux avis en quatre-vingts minutes
La séquence des événements raconte un projet qui a d’abord espéré circonscrire le problème, puis qui a changé d’avis en l’espace d’une heure et demie.
Le 8 novembre à 12 h 33 UTC, LNbits publie un premier avertissement demandant aux opérateurs de désactiver l’extension Paywall, un module qui fait payer l’accès à un contenu, pendant qu’il enquête sur un possible bug. Environ quatre-vingts minutes plus tard, ce message est remplacé par une consigne radicalement plus large : éteignez tous les serveurs. Le projet annonce qu’il a plusieurs correctifs de sécurité à publier et demande aux opérateurs de rester prudents jusqu’à leur sortie.
Le même jour, LNbits a coupé toutes les instances qu’il exploite lui-même sur son service hébergé my.lnbits.com, avec un retour annoncé sous vingt-quatre heures, soit vers 17 h 20 UTC le 9 novembre. La différence est instructive : un fournisseur hébergé peut, lui, décider seul de couper ses services. Un opérateur auto-hébergé doit, lui, lire l’avis, comprendre qu’il est concerné, et agir sur sa propre machine — autant de délais qui s’ajoutent au temps de réaction.
À 09 h 00 UTC le 9 novembre, le projet n’avait toujours pas publié de version corrigée, n’avait pas annulé l’avis, et n’avait pas indiqué comment vérifier si un serveur avait été touché avant sa mise hors service. Ben Arc estimait que les correctifs devraient être fusionnés et disponibles sous vingt-quatre à quarante-huit heures, soit entre le 9 novembre à 14 h 00 UTC et le 10 novembre à 14 h 00 UTC.
Ce qui est en jeu : un portefeuille Lightning n’est pas un blog
Le contraste avec la plupart des incidents auto-hébergés mérite d’être souligné. Quand un Nextcloud ou un Jellyfin est compromis, le préjudice porte sur des données ou du temps de calcul. Quand un portefeuille Lightning est compromis, c’est de l’argent liquide programmable qui part, de manière irréversible et pseudonyme. Les transactions Lightning sont instantanées et ne se rappellent pas : une fois les satoshis transférés, il n’y a ni service client ni chargeback.
Cette asymétrie change la charge de sécurité. Une extension LNbits n’est pas un module de confort : c’est une surface d’attaque qui touche directement aux fonds. Le premier avertissement visait Paywall, ce qui laisse penser que la vulnérabilité se situait dans une extension — un code tiers, moins revu que le cœur, mais qui s’exécute avec les privilèges du portefeuille. C’est le motif classique du self-hosted poussé à l’extrême : la modularité qui rend l’outil utile est aussi celle qui en élargit la surface.
Ce n’est pas la première fois que ce blog documente ce risque sur l’écosystème Lightning. En septembre, Alby avait révélé une faille critique qui vidait les portefeuilles Alby Hub exposés sur Internet, comme détaillé dans notre analyse d’Alby Hub. La leçon se répète presque à l’identique : l’exposition publique d’un portefeuille auto-hébergé transforme une faille logicielle en perte financière immédiate.
Pourquoi l’exposition publique est le multiplicateur de risque
Le même exploit sur une instance LNbits confinée à un réseau local n’aurait pas vidé grand-chose. Ce qui transforme une vulnérabilité d’extension en perte financière, c’est l’exposition publique : une instance joignable depuis Internet par n’importe qui, sans authentification forte, avec des extensions actives. C’est précisément la configuration que Ravensberg exploitait pour servir BitTipBot à des centaines d’utilisateurs sur Telegram — un service public, donc une surface publique.
La frontière se lit dans les deux avis du 8 novembre. Le premier visait une extension, Paywall ; le second visait tous les serveurs. Entre les deux, le projet a compris que le problème n’était pas « une extension » mais « des extensions tournant sur des serveurs exposés ». D’où la consigne radicale de couper plutôt que de corriger à chaud.
Il faut aussi distinguer le portefeuille et le nœud. L’avis d’arrêt concerne les serveurs LNbits et ne mentionne ni les nœuds Lightning ni les autres logiciels de portefeuille : un nœud LND ou Core Lightning seul n’est pas visé par cette consigne. En revanche, tout ce qui expose une interface LNbits — l’application qui gère les clés et les canaux — est concerné.
En pratique, l’opérateur qui a dû couper sans correctif se retrouve dans une position inconfortable : hors ligne, il ne peut ni encaisser ni vérifier en direct. La seule vérification possible est a posteriori, sur les journaux et l’état des canaux : repérer les paiements sortants anormaux dans la fenêtre d’attaque, comparer l’état des canaux avant et après, et révoquer toute clé de nœud qui aurait pu être compromise. C’est un travail d’audit qui ne se termine pas au redémarrage.
Verdict
Si vous exploitez une instance LNbits, le réflexe n’est pas de « surveiller » mais d’éteindre. Coupez l’accès Internet de l’instance, désactivez les extensions — en priorité Paywall — et attendez la sortie des correctifs annoncés par Ben Arc, attendus au plus tard le 10 novembre. Ne redémarrez qu’après avoir appliqué la version corrigée et vérifié que votre nœud n’a pas servi de canal de sortie pendant la fenêtre d’attaque. Si vous hébergez un service Lightning pour des tiers, comme BitTipBot, préparez-vous à la question du remboursement : dans un modèle auto-hébergé, c’est l’opérateur, pas le projet, qui porte la perte. Et plus largement, traitez tout portefeuille Lightning auto-hébergé comme un système financier exposé à Internet : segmentation réseau, accès restreint par VPN, et une règle simple — aucune extension n’est « anodine » dès lors qu’elle touche à des fonds. Le signal fort de cet incident, c’est que le remède immédiat n’a pas été un patch, mais un arrêt d’urgence : quand le correctif se fait attendre, la seule défense qui reste est de couper le courant.