Les développeurs de Core Lightning ont lancé cette semaine une alerte de sécurité après avoir confirmé que plusieurs vulnérabilités signalées dans une série de rapports générés par l’IA étaient réelles. Ils demandent aux opérateurs de nœuds d’installer sans délai une mise à jour de sécurité à venir ou, s’ils ne peuvent pas mettre à jour immédiatement, de redémarrer leurs nœuds avec l’option –offline : en aucun cas il ne faut simplement éteindre la machine.
Pourquoi Core Lightning recommande le redémarrage avec –offline
Core Lightning a expliqué que le flag –offline coupe les connexions entre pairs, empêchant l’entrée, la sortie ou le transit de paiements, tout en gardant le logiciel en fonctionnement pour surveiller la chaîne et agir si un contrepartie force-close un canal. Une machine complètement éteinte ne peut pas surveiller la chaîne et ne pourra pas réagir à une fermeture de canal abusive afin de protéger des fonds.
Le rappel sur l’importance de la surveillance renvoie au fonctionnement des canaux Lightning : deux participants verrouillent du bitcoin dans un canal partagé et mettent à jour hors chaîne la répartition des soldes ; lors de la fermeture du canal, le solde final est inscrit sur la blockchain Bitcoin. Si l’autre partie tente de clore le canal avec un état obsolète, le nœud doit voir cet événement pour répondre on-chain et protéger ses fonds.
Les rapports IA et la procédure de correction
La revue de sécurité a débuté après que la petite équipe de développement de Core Lightning a reçu, sur une période concentrée de dix jours en août, un grand volume de signalements de Common Vulnerabilities and Exposures générés par l’IA provenant de plusieurs sources. L’équipe, assistée de contributeurs externes, a passé ce temps à valider les soumissions et à développer des correctifs. Plusieurs de ces rapports générés par l’IA se sont révélés identifier de vrais problèmes.
Le projet n’a pas divulgué combien de failles ont été confirmées, ce qu’un attaquant pourrait faire avec elles, ni si elles ont été exploitées. Ces informations resteront privées pendant au moins deux semaines pendant que les développeurs préparent les correctifs et que les opérateurs mettent à jour leurs nœuds.
Core Lightning prévoit de distribuer des binaires signés et reproductibles contenant les correctifs, permettant aux opérateurs de vérifier que les fichiers proviennent bien de l’équipe de développement avant installation. Le code source et les détails techniques des vulnérabilités devraient être publiés une fois la période d’embargo de quatorze jours close.
Le développeur Christian Decker a expliqué la raison de cette divulgation différée : comparer du code corrigé avec des versions antérieures facilite souvent l’identification de vulnérabilités et le développement d’attaques exploitables avant que les utilisateurs n’aient pu effectuer leurs mises à jour. L’embargo de quatorze jours offre ainsi une fenêtre de déploiement aux opérateurs.
Le projet a par ailleurs retiré le support des anciennes versions, incluant explicitement la version 26.04. La dernière build étiquetée publiquement avant la diffusion des binaires d’urgence était Core Lightning v26.06.6, tandis que la version 26.09 reste prévue pour la fin septembre.
