Core Lightning mis à jour par Docker ? Comment vérifier que le correctif est bien là

Lorsque votre node Core Lightning affiche v26.06.7 au démarrage, rien ne prouve encore que les correctifs de sécurité de cette version tournent réellement. Qui a tiré sa mise à jour par Docker entre le 28 août 2026 à 16h04 UTC et le 1er septembre exploite peut-être une image qui s'annonce correctement sans contenir les correctifs. La preuve solide, c'est l'empreinte de l'image, et non l'affichage de la version. Ce texte vous guide dans la vérification nécessaire, puis dans ce qu'il faut faire ensuite.

La situation a évolué sur deux points depuis notre article du 30 août : la fenêtre Docker défectueuse est désormais documentée dans la note de version, et l'embargo sur le code source a expiré le 11 septembre. Ces deux éléments modifient la consigne qui vous est adressée en tant qu'exploitant.

Ce qu'est Core Lightning et pourquoi cette mise à jour vous concerne

Core Lightning (anciennement c-lightning) est l'une des trois mises en œuvre répandues du protocole Lightning, écrite en C et entretenue dans le dépôt ElementsProject/lightning. Une implémentation est simplement un programme autonome qui applique les mêmes règles de réseau que les programmes concurrents, mais dispose de son propre code et donc de ses propres défauts.

Le réseau Lightning lui-même est une seconde couche au-dessus de la chaîne de blocs de Bitcoin : deux parties bloquent ensemble des fonds dans un canal de paiement, puis compensent entre elles un nombre quelconque de paiements sans inscrire chacun d'eux dans la chaîne. Qui exploite un tel node détient lui-même les clés de ces fonds bloqués. C'est précisément ce qui rend l'affaire sérieuse : un défaut dans le logiciel du node touche directement du Bitcoin qui vous appartient et dont personne d'autre ne s'occupe.

La conservation autonome signifie la responsabilité personnelle, et celle-ci ne s'arrête pas à la garde de la clé. Elle englobe aussi la question de savoir si le logiciel qui utilise cette clé correspond à l'état que vous croyez avoir installé. Qui préfère détenir ses avoirs sans service serveur permanent trouvera les appareils adaptés dans notre comparatif des portefeuilles matériels. Pour un node Lightning, en revanche, impossible d'échapper à la mise à jour régulière du logiciel en fonctionnement.

Ce qui a mal tourné avec l'image Docker de la version 26.06.7

La version 26.06.7 est parue le 28 août 2026 comme version de maintenance. La communication du projet est brève : il s'agirait d'une version intermédiaire corrigeant des vulnérabilités confirmées, signalées à l'équipe au cours des trois semaines précédentes. Une version intermédiaire est une version qui ne contient que des correctifs et aucune fonction nouvelle.

Pour les utilisateurs de Docker, quelque chose a dérapé. La note de version a été complétée après coup par une section qui nomme le défaut sans détour : entre le 28 août à 16h04 UTC et le 1er septembre, quatre étiquettes ont livré des images qui annonçaient v26.06.7 au démarrage sans contenir les correctifs de cette version. Étaient concernées v26.06.7, latest, v26.06.7-vls et latest-vls.

Le projet nomme lui-même la cause : un processus de construction automatique avait publié les images à partir d'une étiquette de remplissage. Elles ont depuis été remplacées, et les manifestes erronés ne sont plus référencés par aucune étiquette. Un manifeste est le fichier de description qui définit de quelles pièces se compose une image de conteneur. Qui détient encore localement la mauvaise version ne verra toutefois rien de cette correction : sur votre machine reste ce que vous avez chargé à l'époque.

Un point disculpe entièrement une partie des exploitants. Qui était fixé sur v26.06.6 ou une version antérieure n'a, selon le projet, jamais été concerné. Le problème ne touche que ceux qui ont tiré 26.06.7 ou latest pendant la fenêtre indiquée.

Pourquoi le numéro de version au démarrage ne prouve rien du niveau de correctif

La vérification la plus évidente est aussi la plus inutile. Un appel qui vous affiche la version en cours se contente de lire une chaîne de caractères inscrite dans le programme au moment de la construction. Si cette chaîne provient d'une étiquette de remplissage, un programme non corrigé annonce fidèlement le numéro qu'on lui a donné et ne vous dit rien du code réel.

C'est le point désagréable de notre propre article du 30 août : nous vous y faisions vérifier la version. Pour les exploitants Docker pris dans la fenêtre concernée, cette méthode de vérification était sans valeur, sans qu'on ait alors pu s'en apercevoir. D'où ce complément, et d'où une vérification désormais différente.

L'empreinte est la valeur de contrôle qui identifie de manière univoque une image de conteneur. C'est une empreinte cryptographique calculée sur le manifeste, donc sur le contenu réel de l'image. Une étiquette comme latest est un pointeur mobile, susceptible de désigner aujourd'hui une image et demain une autre. L'empreinte ne le peut pas : qu'un seul octet du contenu change et la valeur change. Elle est donc la seule indication qui vous dise ce que vous exploitez réellement.

Êtes-vous concerné ? La fenêtre, les étiquettes et les trois plateformes

Trois questions règlent le cas. Premièrement : avez-vous seulement obtenu le logiciel sous forme de conteneur ? Qui a installé les archives depuis la page de publication n'a jamais été concerné, car ces archives étaient les bonnes dès le départ. Deuxièmement : votre téléchargement se situe-t-il dans la fenêtre comprise entre le 28 août à 16h04 UTC et le 1er septembre ? La note de version n'indique pas d'heure précise pour la fin de cette fenêtre ; il subsiste donc une marge d'incertitude, et dans le doute mieux vaut vérifier une fois de trop. Troisièmement : avez-vous utilisé l'une des quatre étiquettes citées ?

Qui hésite sur les trois questions a toujours raison de lancer la vérification de l'empreinte. Elle vous coûte une seule commande et tranche la question de façon définitive, quels que soient le moment et la manière dont vous avez obtenu l'image.

Les images de cette version existent pour trois plateformes : linux/amd64, linux/arm64 et linux/arm/v7. La troisième présente une particularité qui concerne les exploitants de petits ordinateurs monocartes : il n'existe aucune archive de publication pour linux/arm/v7. Les programmes de cette plateforme sont compilés séparément et ne sont couverts par aucun manifeste signé. Qui travaille sur cette architecture dispose donc d'emblée d'une chaîne de preuve plus faible que sur les deux autres. De plus, selon le projet, les images ne portent ni attestation de provenance ni SBOM, autrement dit aucun justificatif d'origine lisible par une machine.

Comment vérifier l'empreinte de l'image de votre node Lightning

La commande indiquée par la note de version lit l'empreinte de l'image présente localement. Elle se présente ainsi :

docker image inspect --format '{{index .RepoDigests 0}}' elementsproject/lightningd:v26.06.7

La sortie est la valeur que vous devez comparer. Le projet indique deux valeurs de référence pour les images corrigées. Pour les étiquettes v26.06.7 et latest, elle vaut sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. Pour la variante signataire sous v26.06.7-vls et latest-vls, elle vaut sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f.

Deux remarques sur l'exécution. La commande n'interroge que votre stock local, ne télécharge rien et ne modifie rien. Et elle se rapporte à l'étiquette que vous lui indiquez : qui travaille avec latest saisit latest, qui exploite la variante signataire saisit l'étiquette -vls correspondante. Si la valeur affichée correspond caractère pour caractère à la valeur de référence, vous avez terminé et exploitez la version corrigée.

Ce qui compte, c'est la comparaison sur toute la longueur. Un coup d'œil rapide sur les quatre premiers et les quatre derniers caractères ne suffit pas, car c'est précisément la partie qu'un humain laisse passer d'un « ça ira » en cas de doute. Copiez les deux valeurs côte à côte et comparez-les par la machine, par exemple en écrivant la valeur de référence dans un fichier et en contrôlant la sortie contre lui.

L'empreinte diverge : comment récupérer l'image corrigée

Si la valeur diverge, la solution n'a rien de spectaculaire. Vous tirez de nouveau l'image, et ce pour chaque étiquette que vous utilisez effectivement :

docker pull elementsproject/lightningd:v26.06.7
docker pull elementsproject/lightningd:latest

Vous vérifiez ensuite l'empreinte avec la même commande que ci-dessus. C'est seulement lorsque la nouvelle valeur correspond à la référence que vous redémarrez le conteneur, afin que le processus en cours utilise réellement l'image fraîche. Un pull seul ne remplace pas un conteneur en fonctionnement ; votre node continue de tourner sur l'ancien état jusqu'au redémarrage.

Qui exploite des conteneurs via un fichier Compose ou un orchestrateur veillera à ce que la configuration ne retombe pas sur un état local mis en cache. Le plus propre consiste à fixer ensuite l'empreinte vérifiée elle-même au lieu de l'étiquette mobile. La même confusion ne pourra alors plus se reproduire, puisque la référence est liée au contenu et non à un nom.

Un changement de détail peut se remarquer au redémarrage : dans les images actuelles, Core Lightning s'installe dans /usr/bin et /usr/libexec/c-lightning, alors que les images antérieures utilisaient /usr/local. Des liens symboliques depuis les anciens emplacements sont inclus, les chemins codés en dur continuent donc de fonctionner. Qui exploite ses propres scripts avec des chemins absolus devrait tout de même les passer en revue une fois.

Exploitants VLS : pourquoi le signataire doit correspondre à la version du node

VLS signifie Validating Lightning Signer et désigne un service de signature séparé qui conserve les clés du node et contrôle chaque signature au regard de ses propres règles avant de la délivrer. L'idée : même si le node est compromis, un attaquant ne peut pas convaincre le signataire d'autoriser des sorties arbitraires.

Pour ces exploitants, le passage à 26.06.7 comporte une arête dure. La variante v26.06.7-vls contient, selon le projet, le même signataire que v26.06.6-vls, à savoir VLS v0.14.0, que cette publication laisse inchangé. Le signataire exige toutefois que la variable VLS_CLN_VERSION corresponde au node avec lequel il dialogue. Si elle indique encore v26.06.6 alors que le node tourne en v26.06.7, remote_hsmd_socket refuse de démarrer.

C'est désagréable, mais bénin au résultat : le service ne démarre pas du tout, plutôt que de continuer dans un état à moitié cohérent. Ajustez la variable lors de la mise à niveau et le signataire restera joignable. Qui interprète mal le message et ramène le node à l'ancienne version pour faire fonctionner le signataire annule exactement la correction dont il est question ici.

L'embargo a expiré : ce que cela signifie pour les nodes non corrigés

Le projet avait sciemment retenu le code source de cette version. La justification figure dans la note de version : un correctif montre quel code il modifie, et le délai devait réduire la probabilité que des attaquants reconstituent les correctifs et les exploitent avant la mise à jour du réseau.

Ce délai est écoulé. La note de version le dit désormais mot pour mot : « The embargo has ended. The source for this release was published on 2026-09-11T11:42Z. » L'étiquette v26.06.7 pointe depuis lors vers le commit à partir duquel les programmes ont été construits, et l'archive source accompagne la publication.

Pour vous, exploitant, la situation de risque s'inverse. Jusqu'au 11 septembre, un node non corrigé était aussi protégé par le fait que les attaquants n'en connaissaient pas le détail. Cette protection a disparu sans contrepartie, puisque les modifications sont depuis consultables publiquement. Qui n'a pas encore fait la mise à jour exploite un logiciel dont les vulnérabilités sont documentées et accessibles à tous. Le projet précise en outre que les versions antérieures à 26.06.7 ne sont plus prises en charge.

Détail notable en marge, et lisible dans les métadonnées mêmes de la publication : le fichier de signature des sommes de contrôle amd64 n'a été téléversé que le 12 septembre 2026 à 06h02 UTC. Qui voulait vérifier la signature auparavant ne la trouvait pas pour cette architecture. Le fichier de sommes de contrôle, lui, était disponible depuis le 28 août.

Pourquoi le palliatif --offline ne remplace pas la mise à jour

La communication du projet du 28 août contenait une étape intermédiaire pour tous ceux qui ne pouvaient pas actualiser immédiatement. Un redémarrage avec l'option --offline coupe le node des messages entrants et retire ainsi aux attaquants tout moyen de s'adresser à lui. Le service continue de tourner et traite la chaîne de blocs, de sorte qu'il peut encore détecter une tentative de fraude du partenaire de canal. Le projet écrit à ce sujet que l'option doit être retirée après la mise à niveau et le node redémarré.

Ce palliatif était pensé pour la période sans détails publics. Depuis le 11 septembre, il ne remplace plus la mise à jour et ne fait que couvrir les heures dont vous avez besoin pour rattraper le retard. Un node isolé ne relaie aucun paiement, ne gagne aucune commission et reste injoignable pour ses contreparties. Comme état durable, c'est un arrêt coûteux.

La même routine de vérification vaut pour les autres briques de votre installation. Qui place une interface d'administration devant le node devrait aussi connaître son accessibilité depuis le réseau ; pour Alby Hub, nous avons décrit cette démarche le 11 septembre. La situation de départ de cette série de vulnérabilités figure dans notre article du 30 août, Core Lightning : ce que les exploitants de nodes doivent faire maintenant.

Installé sans Docker ? Comment vérifier sommes de contrôle et signatures

Qui récupère les archives depuis la page de publication dispose de la meilleure chaîne de preuve, mais doit encore la parcourir. Chaque fichier de programme est couvert par un manifeste signé. Vous vérifiez d'abord les sommes de contrôle :

sha256sum -c SHA256SUMS-v26.06.7 --ignore-missing

Puis la signature portant sur ce fichier de sommes de contrôle :

gpg --verify SHA256SUMS-v26.06.7.asc SHA256SUMS-v26.06.7

Le fichier SHA256SUMS-v26.06.7 couvre les archives amd64 ; pour arm64, il existe un fichier distinct avec sa propre signature. Quatre mainteneurs du projet ont signé, et la note de version énumère leurs empreintes une à une. Un détail vous évitera une fausse alerte : une signature peut annoncer une empreinte différente de celle qui est répertoriée, parce que les signataires utilisent des sous-clés. Dès que la clé principale est importée, gpg --verify résout cela de lui-même, et l'écart n'est pas un échec de la vérification.

Il existe une seconde preuve, plus rapide, et c'est la partie véritablement élégante de cette publication. Le fichier de sommes de contrôle comportait dès l'origine une ligne pour l'archive source clightning-v26.06.7.zip, alors que cette archive n'était pas encore publique le 28 août. Comme le fichier a été signé à l'époque, il constitue un engagement pris par avance sur exactement les octets publiés aujourd'hui. On peut ainsi montrer en quelques minutes et sans compilateur que le code source visible aujourd'hui est bien celui qui a été signé en août, et que rien n'a été modifié durant l'embargo.

Reconstruction reproductible : où s'arrête la chaîne de preuve de cette version

Une construction reproductible est un processus qui produit, à partir du même code source, exactement le même fichier de programme, octet par octet. Elle permet à des tiers de démontrer de manière indépendante qu'un fichier publié provient bien du code source publié. Pour cette version, cela ne vaut que partiellement, et le projet nomme lui-même les limites.

Premièrement, les archives n'ont pas été construites au niveau d'optimisation par défaut. La configuration utilise par défaut -Og, alors que les programmes publiés ont été produits avec -O3. Qui extrait l'étiquette et construit normalement obtient des fichiers qui ne correspondent pas aux sommes de contrôle ; COPTFLAGS=-O3 doit être indiqué explicitement. Deuxièmement, les archives arm64 ne sont pas reconstructibles depuis cet état, car l'outil nécessaire ne figure pas dans l'arborescence source de cette version. Ces fichiers restent vérifiables par la signature, mais non reproductibles de façon indépendante. Troisièmement, le projet signale que la reconstruction sous Fedora peut diverger, car l'image de construction y est actualisée à chaque exécution et deux personnes travaillant des jours différents peuvent tomber sur des versions d'outils différentes.

Il faut y lire la description honnête d'une chaîne de preuve comportant des trous, et non une critique des personnes impliquées. Pour vous, exploitant, cela signifie en pratique : fiez-vous à la signature et à la somme de contrôle, et traitez la reconstruction complète comme une tâche de spécialistes plutôt que comme une étape de votre routine d'entretien.

Ce que cet incident révèle des chaînes d'approvisionnement du logiciel crypto

La véritable leçon tient à la livraison et non à la vulnérabilité elle-même. Le défaut est né d'un processus de construction automatique qui a publié une image à partir d'un élément de remplissage. Personne n'a eu besoin d'être attaqué pour cela, et pourtant un fichier qui faisait le mauvais travail en revendiquant le bon est resté disponible pendant des jours.

Le projet lui-même avance dans la note de version une raison pour laquelle de telles versions de maintenance devraient se multiplier : des modèles d'intelligence artificielle toujours plus performants sont mobilisés pour débusquer d'éventuelles vulnérabilités dans le code ouvert, ce qui accroît nettement le nombre et le rythme des signalements. Qui exploite une infrastructure devra donc actualiser plus souvent, et la question de savoir comment vérifier une mise à jour devient plus importante que celle de savoir si on l'a effectuée.

Il en découle trois habitudes peu coûteuses en temps. Liez les conteneurs à des empreintes plutôt qu'à des étiquettes mobiles. Après chaque mise à jour, vérifiez le contenu et non l'étiquetage. Et consignez quelle version, avec quelle valeur de contrôle, vous avez déployée et quand, afin de savoir en quelques minutes, au prochain signalement, s'il vous concerne. Qui ne souhaite pas consacrer cet effort à un service serveur permanent devrait examiner honnêtement si une solution de conservation plus légère convient mieux à son quotidien.

Vérifier la mise à jour de Core Lightning : ce qu'il faut en retenir

1. Vérifiez aujourd'hui l'empreinte, et non le numéro de version. Une commande, une comparaison avec la valeur de référence de la note de version, et la question est tranchée. Si vous constatez au passage que l'exploitation d'un node personnel devient trop lourde, notre comparatif des portefeuilles matériels vous donne une vue d'ensemble des solutions de remplacement à la conservation autonome par serveur.
2. Retirez l'image et redémarrez si la valeur diverge. Tirer de nouveau, vérifier encore l'empreinte, remplacer le conteneur, et seulement ensuite retirer l'option --offline. Pour tout ce que vous ferez tourner ensuite comme logiciel sur le node, le comparatif des portefeuilles logiciels mérite un coup d'œil, car la même question des voies de mise à jour et des justificatifs d'origine s'y pose.
3. Organisez votre entretien autour des valeurs de contrôle. Fixer l'empreinte, contrôler sommes de contrôle et signatures après chaque récupération, documenter l'état. Et si vous voulez réapprovisionner des canaux, vous trouverez les moyens dans notre panorama consacré à la manière d'acheter du Bitcoin.

(Au 15 septembre 2026. Cet article ne constitue pas un conseil en investissement. Les cours et les grilles tarifaires évoluent ; vérifiez les conditions auprès du prestataire avant tout achat.)

Sources primaires : la note de version de Core Lightning v26.06.7 dans le dépôt du projet ainsi que la communication de Blockstream sur cette publication.