Alby révèle une faille critique qui vide les portefeuilles Lightning auto-hébergés exposés
Le 9 septembre 2026, Alby avertit que son portefeuille Lightning auto-hébergé Alby Hub contenait, jusqu’à la v1.18.5, une faille critique permettant de prendre le contrôle d’un nœud exposé sur Internet et d’en transférer les fonds. Si vous auto-hébergez un nœud Lightning, vérifiez votre version et coupez l’exposition publique avant toute mise à jour.
9 septembre 2026. Alby publie un avertissement de sécurité sur Alby Hub, son portefeuille Lightning auto-hébergé : une faille critique pouvait permettre à un attaquant de prendre le contrôle d’un nœud exposé sur Internet et d’en transférer les fonds. 7 septembre 2026. Un changement de documentation reconnaît que les guides décrivaient le serveur comme « tournant sur localhost alors qu’il écoute en réalité sur toutes les interfaces réseau ». 29 août 2025. La première version corrigée, v1.19.0, était déjà publiée — mais des milliers de nœuds tournent encore sur une version vulnérable. Pourquoi c’est important : auto-héberger un portefeuille Bitcoin inverse le modèle de confiance, et avec lui, la charge de sécurité.
Une faille qui vide un portefeuille, un seul utilisateur touché à ce jour
Alby Hub est un portefeuille Lightning auto-hébergé : le propriétaire l’exécute sur sa propre machine ou son serveur, et c’est lui qui détient les fonds, sans dépositaire tiers. C’est exactement la promesse du self-hosted appliquée à l’argent — et exactement la raison pour laquelle une faille de ce type ne se répare pas par une mise à jour distante poussée par un fournisseur.
La faille touche les versions v1.7.0 à v1.18.5, toutes publiées avant août 2025. Les versions v1.19.0 et ultérieures ne sont pas affectées. Alby indique qu’un seul utilisateur a été touché à ce jour, sans préciser s’il a perdu de l’argent, et précise que la victime a elle-même signalé l’incident à l’entreprise. La société n’a pas dévoilé la nature technique de la faille — elle publiera les détails plus tard, conformément à une divulgation responsable — et a remercié les chercheurs qui ont signalé d’autres problèmes corrigés dans la dernière version.
Le point qui doit interpeller n’est pas le nombre de victimes, c’est la fenêtre : la faille existait dans le code depuis v1.7.0, le correctif est disponible depuis le 29 août 2025, et l’alerte publique ne tombe que le 9 septembre 2026. Un an s’est écoulé entre le correctif et la révélation, pendant lequel les nœuds non mis à jour sont restés exposés sans le savoir.
Le vrai problème n’est pas le code, c’est l’écoute réseau
La condition d’exploitation change la nature du risque : la faille n’est exploitable que si le Hub est joignable depuis Internet. Sur un Hub qui n’écoute que sur la machine locale, l’attaquant n’a aucun point d’entrée. C’est là que l’histoire devient un cas d’école du self-hosting.
Le serveur web d’Alby Hub n’écoute pas seulement sur 127.0.0.1 : il écoute sur toutes les interfaces réseau de la machine. Une documentation qui dit « ça tourne en localhost » est donc fausse en pratique — et c’est précisément ce qu’a reconnu le changement de documentation fusionné le 7 septembre 2026. La même modification a basculé le fichier Docker du projet pour publier le port 8080 uniquement sur la machine (127.0.0.1:8080:8080) au lieu de l’exposer à toutes les adresses (8080:8080).
La conséquence est mécanique : toute personne qui a suivi un guide de déploiement sur un serveur cloud, puis ouvert le port 8080 dans le pare-feu, a exposé son portefeuille à l’Internet entier. Le Hub exige un mot de passe pour se déverrouiller, mais une faille de prise de contrôle contourne précisément cette protection — c’est tout l’enjeu d’une vulnérabilité critique par rapport à une simple erreur de configuration.
Des guides qui orientent encore vers l’exposition
Le plus troublant, c’est que l’exposition n’est pas seulement un accident d’utilisateur : elle est encore documentée. Au 9 septembre 2026, jour de l’alerte, les guides officiels d’Alby pour déployer un Hub sur un serveur cloud décrivaient toujours une configuration ouverte sur Internet.
Le guide DigitalOcean dit au lecteur de laisser l’adresse publique du serveur activée, « nécessaire pour ouvrir Alby Hub dans votre navigateur », puis d’ouvrir le Hub à cette adresse. Le guide Hetzner déroule une règle de pare-feu pour le port 8080 avec la source réglée sur « Any IPv4 et Any IPv6, ou votre propre adresse IP pour une meilleure sécurité » — l’exposition totale étant présentée comme l’option par défaut, et la restriction comme une optimisation. L’exemple Docker du guide publie le port vers toutes les adresses.
Cette asymétrie est la leçon centrale : un logiciel self-hosted peut être corrigé côté code sans que les chemins d’installation — guides, fichiers Compose, presets de pare-feu — ne le soient jamais. La faille était corrigée dans le binaire depuis un an ; les instructions qui exposent le binaire, elles, étaient encore en ligne le jour de l’alerte.
Un précédent en novembre 2025
Ce n’est pas la première fois qu’un Hub exposé se fait vider. En novembre 2025, répondant à un utilisateur dont le Hub avait été vidé, Alby avait expliqué que la machine était « joignable publiquement sur le clearnet, donc accessible depuis l’extérieur ». Par le récit d’Alby, il s’agissait d’un problème différent : l’installation n’avait jamais été terminée, aucun mot de passe de déverrouillage n’existait encore, et l’attaquant avait simplement achevé la configuration à sa place.
Après ce cas, une modification de l’application Umbrel a placé Alby Hub derrière la connexion d’Umbrel — qui avait été désactivée pour lui jusque-là. Le store Umbrel installe désormais la v1.24.0, et la fiche Umbrel d’Alby installe la v1.21.4, toutes deux plus récentes que la version corrigée. Mais cela décrit ce que ces stores installent aujourd’hui, pas ce que tourne réellement un nœud déjà déployé.
L’épisode de novembre 2025 et celui de septembre 2026 se font écho : dans les deux cas, la vulnérabilité n’est pas dans l’idée du self-hosting, elle est dans le réflexe d’exposer un service d’argent au réseau public alors qu’il a été conçu pour vivre sur un réseau privé.
Ce qu’il faut faire maintenant
La marche à suivre publiée par Alby tient en quatre gestes, dans un ordre précis :
- Vérifiez la version de votre Hub — si elle est v1.18.5 ou antérieure, vous êtes dans le périmètre affecté ;
- Coupez d’abord l’exposition — en Docker, publiez
127.0.0.1:8080:8080et non8080:8080; sur un serveur cloud, restreignez la règle de pare-feu du port 8080 à votre seule adresse ; - Mettez à jour vers v1.24.0, la version courante — Alby la recommande même aux nœuds non affectés ;
- Si votre nœud était affecté et exposé, changez votre mot de passe de déverrouillage après la mise à jour et écrivez à
[email protected].
L’ordre compte : la mise à jour n’efface pas un accès qu’un attaquant aurait déjà obtenu sur un Hub exposé. Couper l’exposition d’abord, puis patcher, puis changer le secret — c’est la séquence qui neutralise à la fois la faille et sa conséquence.
Verdict
L’affaire Alby Hub est un rappel de ce que signifie réellement « être sa propre banque ». Le self-hosted supprime l’intermédiaire qui, d’habitude, patche à votre place et absorbe la fuite à votre place — il vous laisse les clés, et la responsabilité entière de la porte.
Si vous auto-hébergez un portefeuille Lightning, appliquez la posture d’un service de production, pas celle d’un gadget de laboratoire : bind en 127.0.0.1, jamais d’écoute sur 0.0.0.0, et accès distant uniquement via un tunnel privé — Tailscale ou WireGuard — plutôt qu’un reverse proxy exposé en clair. Épinglez vos versions, surveillez les annonces du projet, et traitez toute exposition publique comme une exception qui doit se justifier, pas comme le réglage par défaut.
Si vous tenez un nœud Lightning qui n’est pas le vôtre — un Umbrel, un Start9, un serveur partagé — vérifiez que le port 8080 n’est pas ouvert vers l’extérieur, même si la version est à jour : c’est la première ligne de défense, celle qui rend la prochaine faille critique inexploitable avant même qu’elle soit annoncée.