Core Lightning per Docker aktualisiert? So prüfst du, ob das Sicherheitsupdate wirklich drin ist

Wenn dein Core-Lightning-Knoten beim Start v26.06.7 ausgibt, ist das noch kein Beleg dafür, dass die Sicherheitskorrekturen dieser Version auch wirklich laufen. Wer sein Update zwischen dem 28. August 2026, 16:04 UTC, und dem 1. September per Docker gezogen hat, betreibt unter Umständen ein Abbild, das sich korrekt meldet und die Korrekturen trotzdem nicht enthält. Der belastbare Nachweis ist der Image-Digest, nicht die Versionsausgabe. Dieser Text führt dich durch die Prüfung, die dafür nötig ist, und durch das, was danach zu tun ist.

Die Lage hat sich seit unserem Artikel vom 30. August an zwei Stellen verändert: Das fehlerhafte Docker-Fenster ist inzwischen in der Release-Notiz dokumentiert, und die Sperrfrist für den Quellcode ist am 11. September abgelaufen. Beides ändert die Handlungsanweisung an dich als Betreiber.

Was Core Lightning ist und warum dich dieses Update betrifft

Core Lightning (früher c-lightning) ist eine von drei verbreiteten Umsetzungen des Lightning-Protokolls, geschrieben in C und gepflegt im Repository ElementsProject/lightning. Eine Implementierung ist dabei schlicht ein eigenständiges Programm, das dieselben Netzwerkregeln umsetzt wie die Konkurrenzprogramme, aber eigenen Code hat und damit auch eigene Fehler.

Das Lightning-Netzwerk selbst ist eine zweite Ebene über der Bitcoin-Blockchain: Zwei Parteien sperren gemeinsam Geld in einem Zahlungskanal und verrechnen danach beliebig viele Zahlungen untereinander, ohne jede einzelne davon in die Kette zu schreiben. Wer einen solchen Knoten betreibt, hält die Schlüssel zu diesem gesperrten Geld selbst. Genau das macht die Sache ernst: Ein Fehler in der Knotensoftware trifft unmittelbar Bitcoin, das dir gehört und auf das niemand sonst aufpasst.

Selbstverwahrung heißt Eigenverantwortung, und die endet nicht beim Aufbewahren des Schlüssels. Dazu gehört auch die Frage, ob die Software, die diesen Schlüssel benutzt, dem Stand entspricht, den du glaubst installiert zu haben. Wer seine Bestände lieber ohne laufenden Serverdienst hält, findet die Geräte dafür in unserem Vergleich der Hardware-Wallets. Für einen Lightning-Knoten führt jedoch kein Weg daran vorbei, laufende Software aktuell zu halten.

Was beim Docker-Abbild von Version 26.06.7 schiefgelaufen ist

Die Version 26.06.7 erschien am 28. August 2026 als Wartungsrelease. Die Projektmitteilung dazu ist knapp: Es handle sich um ein Point Release, das bestätigte Schwachstellen behebe, die dem Team in den drei Wochen zuvor gemeldet worden seien. Ein Point Release ist eine Zwischenversion, die ausschließlich Korrekturen enthält und keine neuen Funktionen.

Für Docker-Nutzer ging dabei etwas schief. Die Release-Notiz wurde nachträglich um einen Abschnitt ergänzt, der den Fehler beim Namen nennt: Zwischen dem 28. August um 16:04 UTC und dem 1. September lieferten vier Tags Abbilder aus, die beim Start v26.06.7 meldeten, die Korrekturen dieser Version aber nicht enthielten. Betroffen waren v26.06.7, latest, v26.06.7-vls und latest-vls.

Die Ursache benennt das Projekt selbst: Ein automatischer Bauprozess hatte die Abbilder aus einem Platzhalter-Tag veröffentlicht. Inzwischen sind sie ersetzt, und die falschen Manifeste werden von keinem Tag mehr referenziert. Ein Manifest ist die Beschreibungsdatei, die festlegt, aus welchen Einzelteilen ein Container-Abbild besteht. Wer die falsche Fassung noch lokal liegen hat, merkt von dieser Korrektur allerdings nichts: Auf deinem Rechner bleibt das, was du damals geladen hast.

Ein Punkt entlastet einen Teil der Betreiber vollständig. Wer fest auf v26.06.6 oder älter festgelegt war, war nach Angaben des Projekts zu keinem Zeitpunkt betroffen. Das Problem trifft ausschließlich jene, die im genannten Fenster auf 26.06.7 oder auf latest gezogen haben.

Warum die Versionsnummer beim Start kein Beleg für den Patch-Stand ist

Die naheliegende Prüfung ist auch die nutzlose. Ein Aufruf, der dir die laufende Version ausgibt, liest lediglich eine Zeichenkette aus, die beim Bauen in das Programm geschrieben wurde. Stammt diese Zeichenkette aus einem Platzhalter-Tag, dann meldet ein ungepatchtes Programm wahrheitsgemäß die Nummer, die man ihm mitgegeben hat, und sagt dir über den tatsächlichen Code nichts.

Das ist die unangenehme Stelle in unserem eigenen Artikel vom 30. August: Dort haben wir dich die Version prüfen lassen. Für Docker-Betreiber aus dem betroffenen Fenster war dieser Prüfweg wertlos, ohne dass das damals erkennbar gewesen wäre. Deshalb steht hier der Nachtrag, und deshalb ist die Prüfung ab jetzt eine andere.

Der Digest ist der Prüfwert, der ein Container-Abbild eindeutig identifiziert. Er ist ein kryptografischer Hash über das Manifest, also über den tatsächlichen Inhalt des Abbilds. Ein Tag wie latest ist ein beweglicher Zeiger, der heute auf dieses und morgen auf ein anderes Abbild zeigen kann. Der Digest kann das nicht: Ändert sich auch nur ein Byte am Inhalt, ändert sich der Wert. Er ist damit die einzige Angabe, die dir sagt, was du wirklich betreibst.

Bist du betroffen? Zeitfenster, Tags und die drei Plattformen

Drei Fragen klären den Fall. Erstens: Hast du die Software überhaupt als Container bezogen? Wer die Tarballs von der Release-Seite installiert hat, war nie betroffen, denn diese Archive waren von Anfang an die richtigen. Zweitens: Lag dein Bezug im Fenster zwischen dem 28. August 16:04 UTC und dem 1. September? Die Release-Notiz nennt für das Ende dieses Fensters keine genaue Uhrzeit, es bleibt also ein Rest an Unschärfe, und im Zweifel prüfst du lieber einmal zu viel. Drittens: Hast du eines der vier genannten Tags verwendet?

Wer bei allen drei Fragen unsicher ist, liegt mit der Digest-Prüfung immer richtig. Diese Prüfung kostet dich einen einzigen Befehl und beantwortet die Frage abschließend, ganz gleich wann und wie du das Abbild bezogen hast.

Für die Abbilder dieser Version gibt es drei Plattformen: linux/amd64, linux/arm64 und linux/arm/v7. Die dritte hat eine Besonderheit, die Betreiber kleiner Einplatinenrechner angeht: Für linux/arm/v7 existiert kein Release-Tarball. Die Programme dieser Plattform werden separat übersetzt und sind von keinem signierten Manifest gedeckt. Wer auf dieser Architektur arbeitet, hat also von vornherein eine schwächere Nachweiskette als auf den beiden anderen. Zudem tragen die Abbilder nach Angaben des Projekts weder Provenance- noch SBOM-Attestierungen, also keine maschinenlesbaren Herkunftsnachweise.

So prüfst du den Image-Digest deines Lightning-Knotens

Der Befehl, den die Release-Notiz nennt, liest den Digest des lokal vorliegenden Abbilds aus. Er sieht so aus:

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

Die Ausgabe ist der Wert, den du vergleichen musst. Das Projekt nennt für die korrigierten Abbilder zwei Sollwerte. Für die Tags v26.06.7 und latest lautet er sha256:0421a5f0d1b2e1ad639edfa17d777816040e3850d91bae7f2d32186d9c1e6da4. Für die Signer-Variante unter v26.06.7-vls und latest-vls lautet er sha256:6a5e05c13a65613f8c0fe3830c60248a6724e7206c1c23dd26ac2e98a3e72c1f.

Zwei Hinweise zur Ausführung. Der Befehl fragt ausschließlich deinen lokalen Bestand ab, er lädt nichts nach und verändert nichts. Und er bezieht sich auf das Tag, das du ihm nennst: Wer mit latest arbeitet, setzt latest ein, wer die Signer-Variante betreibt, das jeweilige -vls-Tag. Stimmt der ausgegebene Wert Zeichen für Zeichen mit dem Sollwert überein, bist du fertig und betreibst die korrigierte Fassung.

Wichtig ist der Abgleich über die volle Länge. Ein flüchtiger Blick auf die ersten und letzten vier Zeichen reicht nicht, weil genau das der Teil ist, den ein Mensch im Zweifel als „passt schon" durchwinkt. Kopiere beide Werte nebeneinander und vergleiche sie maschinell, etwa indem du den Sollwert in eine Datei schreibst und die Ausgabe dagegen prüfst.

Digest weicht ab: So ziehst du das korrigierte Abbild nach

Weicht der Wert ab, ist die Lösung unspektakulär. Du ziehst das Abbild neu, und zwar für jedes Tag, das du tatsächlich verwendest:

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

Danach prüfst du den Digest erneut mit demselben Befehl wie oben. Erst wenn der neue Wert dem Sollwert entspricht, startest du den Container neu, damit der laufende Prozess auch tatsächlich das frische Abbild benutzt. Ein pull allein tauscht einen laufenden Container nicht aus; dein Knoten läuft bis zum Neustart weiter auf dem alten Stand.

Wer Container über eine Compose-Datei oder einen Orchestrierer betreibt, achtet darauf, dass die Konfiguration nicht auf einen zwischengespeicherten lokalen Stand zurückfällt. Am saubersten arbeitest du, indem du im Anschluss statt des beweglichen Tags den geprüften Digest selbst festschreibst. Dann kann dir dieselbe Verwechslung kein zweites Mal passieren, weil der Bezug an den Inhalt gebunden ist und nicht an einen Namen.

Eine Änderung am Rand kann beim Neustart auffallen: Core Lightning wird in den aktuellen Abbildern nach /usr/bin und /usr/libexec/c-lightning installiert, während frühere Abbilder /usr/local verwendeten. Symlinks von den alten Orten sind enthalten, fest verdrahtete Pfade funktionieren also weiter. Wer eigene Skripte mit absoluten Pfaden betreibt, sollte sie trotzdem einmal durchsehen.

VLS-Betreiber: Warum der Signer zur Knotenversion passen muss

VLS steht für Validating Lightning Signer und bezeichnet einen abgetrennten Signierdienst, der die Schlüssel des Knotens verwahrt und jede Signatur gegen eigene Regeln prüft, bevor er sie ausstellt. Der Sinn dahinter: Selbst wenn der Knoten kompromittiert wird, kann ein Angreifer den Signer nicht zu beliebigen Ausgaben überreden.

Für diese Betreiber gibt es beim Wechsel auf 26.06.7 eine harte Kante. Die Variante v26.06.7-vls enthält nach Angaben des Projekts denselben Signer wie v26.06.6-vls, nämlich VLS v0.14.0, der von diesem Release unverändert bleibt. Der Signer verlangt aber, dass die Variable VLS_CLN_VERSION zu dem Knoten passt, mit dem er spricht. Steht dort noch v26.06.6, während der Knoten auf v26.06.7 läuft, verweigert remote_hsmd_socket den Start.

Das ist unangenehm, aber im Ergebnis gutartig: Der Dienst startet gar nicht erst, statt in einem halb passenden Zustand weiterzulaufen. Setze die Variable beim Upgrade mit, dann bleibt der Signer erreichbar. Wer die Meldung falsch deutet und den Knoten wieder auf die alte Version zurückdreht, um den Signer zum Laufen zu bringen, macht genau die Korrektur rückgängig, um die es hier geht.

Die Sperrfrist ist abgelaufen: Was das für ungepatchte Knoten bedeutet

Das Projekt hatte den Quellcode zu dieser Version bewusst zurückgehalten. Die Begründung steht in der Release-Notiz: Ein Patch zeigt, welchen Code er ändert, und die Verzögerung sollte die Wahrscheinlichkeit senken, dass Angreifer die Korrekturen zurückentwickeln und ausnutzen, bevor das Netzwerk aktualisiert ist.

Diese Frist ist vorbei. Die Release-Notiz sagt es inzwischen wörtlich: „The embargo has ended. The source for this release was published on 2026-09-11T11:42Z." Der Tag v26.06.7 zeigt seither auf den Commit, aus dem die Programme gebaut wurden, und das Quellarchiv liegt der Veröffentlichung bei.

Für dich als Betreiber kehrt sich damit die Risikolage um. Bis zum 11. September war ein ungepatchter Knoten auch dadurch geschützt, dass Angreifer die Einzelheiten nicht kannten. Dieser Schutz ist ersatzlos entfallen, denn die Änderungen sind seither öffentlich nachlesbar. Wer bis heute nicht nachgezogen hat, betreibt eine Software, deren Schwachstellen dokumentiert und für jeden einsehbar sind. Das Projekt hält zudem fest, dass Versionen vor 26.06.7 nicht mehr unterstützt werden.

Bemerkenswert am Rand, und aus den Metadaten der Veröffentlichung selbst ablesbar: Die Signaturdatei zu den amd64-Prüfsummen wurde erst am 12. September 2026 um 06:02 UTC hochgeladen. Wer die Signatur vorher prüfen wollte, fand sie für diese Architektur nicht vor. Die Prüfsummendatei selbst lag dagegen seit dem 28. August bereit.

Warum der Notbehelf --offline kein Ersatz für das Update ist

In der Projektmitteilung vom 28. August stand ein Zwischenschritt für alle, die nicht sofort aktualisieren konnten. Ein Neustart mit dem Schalter --offline schneidet den Knoten von eingehenden Nachrichten ab und nimmt Angreifern damit den Weg, ihn überhaupt anzusprechen. Der Dienst läuft dabei weiter und verarbeitet die Blockchain, sodass er einen Betrugsversuch des Kanalpartners noch erkennen kann. Das Projekt schreibt dazu, der Schalter solle nach dem Upgrade wieder entfernt und der Knoten neu gestartet werden.

Dieser Behelf war für die Zeit ohne öffentliche Einzelheiten gedacht. Seit dem 11. September ist er kein Ersatz mehr für das Update, sondern nur noch eine Überbrückung für die Stunden, die du bis zum Nachziehen brauchst. Ein abgeschotteter Knoten leitet keine Zahlungen weiter, verdient keine Gebühren und ist für Gegenstellen nicht erreichbar. Als Dauerzustand ist das ein teurer Stillstand.

Die gleiche Prüfroutine lohnt sich für andere Bausteine im eigenen Aufbau. Wer eine Verwaltungsoberfläche vor den Knoten setzt, sollte auch deren Erreichbarkeit aus dem Netz kennen; für Alby Hub haben wir diesen Weg am 11. September beschrieben. Die Ausgangslage zu dieser Schwachstellenserie steht in unserem Artikel vom 30. August, Core Lightning: Was Node-Betreiber jetzt tun müssen.

Ohne Docker installiert? So verifizierst du Prüfsummen und Signaturen

Wer die Tarballs von der Release-Seite bezieht, hat den besseren Nachweisweg, muss ihn aber auch gehen. Jede Programmdatei ist von einem signierten Manifest gedeckt. Zuerst prüfst du die Prüfsummen:

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

Danach die Signatur über diese Prüfsummendatei:

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

Die Datei SHA256SUMS-v26.06.7 deckt die amd64-Archive ab, für arm64 gibt es eine eigene Datei mit eigener Signatur. Signiert haben vier Maintainer des Projekts, deren Fingerabdrücke die Release-Notiz einzeln auflistet. Ein Detail erspart dir dabei einen Fehlalarm: Eine Signatur kann einen Fingerabdruck melden, der von dem gelisteten abweicht, weil die Signierenden Unterschlüssel verwenden. Sobald der Hauptschlüssel importiert ist, löst gpg --verify das selbst auf, und die Abweichung ist kein Fehlschlag der Prüfung.

Es gibt noch einen zweiten, schnelleren Nachweis, und der ist der eigentlich elegante Teil dieser Veröffentlichung. Die Prüfsummendatei enthielt von Anfang an eine Zeile für das Quellarchiv clightning-v26.06.7.zip, obwohl dieses Archiv am 28. August noch gar nicht öffentlich war. Weil die Datei damals signiert wurde, ist sie eine im Voraus abgegebene Festlegung auf genau die Bytes, die jetzt veröffentlicht sind. Damit lässt sich in Minuten und ohne Compiler zeigen, dass der heute sichtbare Quellcode derselbe ist, der im August signiert wurde, und dass während der Sperrfrist nichts verändert wurde.

Reproduzierbarer Nachbau: Wo die Prüfkette dieser Version endet

Ein reproduzierbarer Build ist ein Bauvorgang, der aus demselben Quellcode Byte für Byte dieselbe Programmdatei erzeugt. Er erlaubt Dritten, unabhängig nachzuweisen, dass eine veröffentlichte Datei tatsächlich aus dem veröffentlichten Quellcode stammt. Bei dieser Version gilt das nur eingeschränkt, und das Projekt benennt die Einschränkungen selbst.

Erstens wurden die Archive nicht mit der Standard-Optimierungsstufe gebaut. Die Konfiguration nutzt vorgabegemäß -Og, die veröffentlichten Programme entstanden mit -O3. Wer den Tag auscheckt und normal baut, bekommt Dateien, die nicht zu den Prüfsummen passen; COPTFLAGS=-O3 muss ausdrücklich mitgegeben werden. Zweitens sind die arm64-Archive aus diesem Stand nicht nachbaubar, weil das dafür nötige Werkzeug nicht im Quellbaum dieser Version liegt. Diese Dateien bleiben über die Signatur prüfbar, aber nicht unabhängig reproduzierbar. Drittens weist das Projekt darauf hin, dass der Fedora-Nachbau abweichen kann, weil das dortige Bauabbild bei jedem Lauf frisch aktualisiert wird und zwei Personen an verschiedenen Tagen unterschiedliche Werkzeugstände erwischen können.

Das ist als ehrliche Beschreibung einer Prüfkette mit Lücken zu lesen, nicht als Kritik an den Beteiligten. Für dich als Betreiber heißt es praktisch: Verlasse dich auf Signatur und Prüfsumme, und behandle den vollständigen Nachbau als Aufgabe für Spezialisten, nicht als Schritt deiner Wartungsroutine.

Was der Vorfall über Lieferketten bei Krypto-Software zeigt

Der eigentliche Lehrsatz steckt in der Auslieferung und nicht in der Schwachstelle selbst. Der Fehler entstand in einem automatischen Bauprozess, der ein Abbild aus einem Platzhalter veröffentlichte. Niemand musste dafür angegriffen werden, und trotzdem stand tagelang eine Datei bereit, die das Falsche tat und das Richtige behauptete.

Das Projekt selbst nennt in der Release-Notiz einen Grund, warum solche Wartungsreleases künftig häufiger werden dürften: Immer leistungsfähigere KI-Modelle werden eingesetzt, um mögliche Schwachstellen in quelloffenem Code aufzuspüren, was Zahl und Tempo der Meldungen deutlich erhöht. Wer Infrastruktur betreibt, wird also öfter aktualisieren müssen, und damit wird die Frage, wie man eine Aktualisierung überprüft, wichtiger als die Frage, ob man sie durchgeführt hat.

Daraus folgen drei Gewohnheiten, die wenig Zeit kosten. Binde Container an Digests statt an bewegliche Tags. Prüfe nach jedem Update den Inhalt und nicht die Beschriftung. Und halte fest, welche Version mit welchem Prüfwert du wann ausgerollt hast, damit du bei der nächsten Meldung in Minuten weißt, ob sie dich betrifft. Wer diesen Aufwand für einen laufenden Serverdienst nicht treiben möchte, sollte ehrlich prüfen, ob eine schlankere Verwahrlösung besser zum eigenen Alltag passt.

Core Lightning Update prüfen: Was du daraus mitnimmst

1. Prüfe heute den Digest, nicht die Versionsnummer. Ein Befehl, ein Vergleich mit dem Sollwert aus der Release-Notiz, und die Frage ist beantwortet. Wenn du dabei merkst, dass dir der Betrieb eines eigenen Knotens zu aufwendig wird, verschaffst du dir mit unserem Hardware-Wallet-Vergleich einen Überblick über die Alternativen zur reinen Selbstverwahrung per Server.
2. Zieh nach und starte neu, wenn der Wert abweicht. Neu ziehen, Digest erneut prüfen, Container austauschen, und erst danach den Schalter --offline entfernen. Für alles, was du danach an Software am Knoten betreibst, lohnt der Blick in den Software-Wallet-Vergleich, weil dort dieselbe Frage nach Update-Wegen und Herkunftsnachweisen zählt.
3. Richte deine Wartung auf Prüfwerte aus. Digest festschreiben, Prüfsummen und Signaturen nach jedem Bezug kontrollieren, den Stand dokumentieren. Und wenn du Kanäle nachfinanzieren willst, findest du die Wege dafür in unserer Übersicht, wie du Bitcoin kaufst.

(Stand: 15. September 2026. Dieser Beitrag ist keine Anlageberatung. Kurse und Gebührenmodelle ändern sich; prüfe die Konditionen vor jedem Kauf beim Anbieter selbst.)

Primärquellen: die Release-Notiz zu Core Lightning v26.06.7 im Repository des Projekts sowie die Projektmitteilung von Blockstream zum Release.