Core Lightning confirme des failles de sécurité et appelle les opérateurs à mettre à jour sans délai

Core Lightning a confirmé la présence de plusieurs failles de sécurité dans son implémentation du Lightning Network et demande aux opérateurs de nœuds d'installer dès sa publication une mise à jour de sécurité en préparation. Mesure provisoire recommandée : pour les opérateurs qui ne peuvent pas appliquer la mise à jour immédiatement, le projet conseille de démarrer le nœud avec l'option "offline" afin de couper les connexions et d'interrompre le routage des paiements, tout en laissant le démon actif pour continuer à surveiller la blockchain Bitcoin. Origine de l'alerte Les développeurs ont passé au crible un important lot de signalements CVE générés par IA. Plusieurs rapports se sont avérés fondés et ont mis en évidence de vraies vulnérabilités nécessitant des correctifs. L'équipe n'a pas publié de détails techniques et demande de donner la priorité à l'installation de la version de sécurité dès qu'elle sera disponible. À quoi sert le mode "offline" (et pourquoi ne pas arrêter le nœud) Le mode "offline" maintient le démon Core Lightning en fonctionnement, ce qui lui permet de suivre la chaîne Bitcoin et de réagir si une contrepartie force la fermeture ("force-close") d'un canal. Un nœud totalement arrêté ne peut plus observer la chaîne ; si un partenaire de canal publie des transactions sur Bitcoin pendant cette période, l'opérateur peut manquer l'événement et perdre la possibilité de répondre. Core Lightning recommande donc de conserver le démon actif en mode "offline" plutôt que de l'arrêter. Une fois la version corrigée installée, il faut retirer l'option "offline" : la laisser activée après la mise à jour maintient le nœud déconnecté et empêche toute activité Lightning normale. Zones d'ombre Core Lightning n'a communiqué ni identifiants CVE publics, ni niveau de gravité, ni composants ou versions affectés, et aucune preuve publique n'indique une exploitation active de ces failles. Les opérateurs devront donc se référer aux instructions qui accompagneront la prochaine publication de sécurité pour déterminer si leur installation est concernée. Contexte Ces vulnérabilités confirmées sont distinctes des failles de déni de service divulguées plus tôt cette année, liées à une exhaustion mémoire dans connectd (gestion des pairs) et gossipd (traitement des messages de "gossip"). Ces problèmes permettaient à des pairs distants de déclencher une consommation mémoire non bornée et avaient été corrigés avant l'alerte actuelle. L'article rappelle que des mises à jour de sécurité imposant une action des opérateurs sont régulières dans l'écosystème Bitcoin, citant notamment des correctifs récents dans Bitcoin Core (dont CVE202452911, un bug de validation de blocs corrigé dans Bitcoin Core 29.0), ainsi que des incidents côté clients Lightning : la fuite mémoire de LND 0.16.3 à la mi-2023 et des travaux de recherche sur l'attaque dite "replacement-cycling" apparus plus tard la même année. Core Lightning indique que plusieurs soumissions CVE générées par IA étaient valides, tout en s'abstenant de publier des chemins d'exploitation, fonctions concernées ou étapes de reproduction tant que les correctifs ne sont pas finalisés. Mesures pratiques pour les opérateurs 1. Surveiller la publication de la version de sécurité Core Lightning et l'installer dès qu'elle est disponible. 2. Si la mise à jour ne peut pas être appliquée immédiatement, redémarrer Core Lightning avec l'option "offline" pour empêcher les connexions entre pairs et le routage des paiements, tout en conservant la surveillance de la blockchain. 3. Ne pas arrêter complètement le démon sans mesurer le risque de manquer des transactions de force-close de canaux. 4. Après l'installation du correctif, retirer "offline" avant de redémarrer afin de permettre la reconnexion et la reprise des paiements et du routage. Aucune perte ni attaque avérée n'a été rapportée à ce stade sur la base des informations divulguées par Core Lightning. Le projet demande de traiter l'avis comme urgent : appliquer la mise à jour dès sa publication et n'utiliser "offline" qu'en mesure de mitigation temporaire.