Core Lightning: Betreiber sollen Version und Docker-Digest prüfen

Core Lightning, eine der verbreiteten Implementierungen für das Lightning Network, hat mit Version 26.06.7 einen Fehler in der Channel-Schließlogik behoben. Unter einer engen Bedingung konnte ein Peer einen alten, bereits widerrufenen Kanalzustand veröffentlichen, ohne dass die dafür vorgesehene Strafzahlung ausgelöst wurde.

Bestätigte Fälle von Diebstahl nennt das Projekt nicht. Dokumentiert ist eine mögliche Umgehung des Penalty-Mechanismus, die Bitcoin Optech am Freitag, 25. September, öffentlich erläuterte.

Fehler bei der Erkennung widerrufener Channel-Zustände

Im Lightning Network ersetzen Peers frühere Channel-Commitments, sobald sich die Salden zwischen zwei Parteien ändern. Veröffentlicht ein Peer trotzdem ein bereits widerrufenes Commitment, soll die Gegenpartei eigentlich eine Strafzahlung durchsetzen können.

Vor dem Fix konnte Core Lightning einen solchen Funding-Spend fälschlicherweise als kooperativen Close einstufen, sofern dessen Outputs bereits bekannten Shutdown-Skripten entsprachen. Dieser Pfad setzte voraus, dass beim Öffnen des Kanals kein Upfront-Shutdown-Skript festgelegt worden war. Ein Peer konnte in diesem Fall das Output-Skript seines widerrufenen Commitments später in einer Shutdown-Nachricht angeben, den kooperativen Close abbrechen und stattdessen das alte Commitment broadcasten.

Der jetzige Fix prüft Locktime und Sequence-Kodierung einer Transaktion, bevor deren Outputs überhaupt als mögliches Ziel eines Mutual Close bewertet werden. Version 26.06.7 erschien am 28. August, Pull Request #9509 mit den entsprechenden Änderungen wurde am 15. September in den Entwicklungszweig gemerged. Am 22. September folgte mit v26.06.8 eine weitere Sicherheitsversion mit zusätzlichen Fixes.

Hintergrund: Patch, Quellcode und Docker-Hinweise

Betreiber eines Core-Lightning-Builds, der älter als v26.06.7 ist, sollten aktualisieren. Das Projekt empfiehlt ausdrücklich v26.06.8 als aktuelle Sicherheitsversion; der Quellcode zu v26.06.7 selbst wurde erst am 11. September veröffentlicht.

Wer während des früheren Rollouts Docker-Images genutzt hat, sollte zudem den Image-Digest prüfen. Nach Angaben des Projekts konnte ein Image die neue Versionsnummer beim Start melden, ohne die eigentlichen Fixes zu enthalten – ein einfacher Blick auf die angezeigte Version reicht daher nicht aus. Wichtig ist auch die Einordnung: Die Schwachstelle betrifft ausschließlich die Channel-Behandlung von Core Lightning, nicht die Konsensregeln der Bitcoin-Basisschicht. Für Betreiber unterstreicht der Vorfall, dass eine korrekte Channel-Behandlung wichtig ist: Die dokumentierte Schwachstelle konnte unter den beschriebenen Bedingungen eine vorgesehene Strafzahlung umgehen.

Markteinordnung und Ausblick

Ein direkter Preiseffekt auf Bitcoin lässt sich aus der Meldung nicht ableiten – betroffen sind primär Betreiber, nicht Märkte. Relevant ist der Vorfall vor allem für Node-Betreiber mit älteren Core-Lightning-Versionen oder potenziell fehlerhaften Docker-Images.

Nicht jeder Kanal aus einer älteren Version war über diesen Weg tatsächlich angreifbar, da der Penalty-Umgehungspfad die beschriebene Shutdown-Skript-Bedingung voraussetzte. Für Betreiber bleiben zwei konkrete Schritte: das Software-Upgrade auf v26.06.8 und der Abgleich des verwendeten Docker-Image-Digests mit den offiziellen Angaben des Projekts.