Die in diesem Artikel bereitgestellten Informationen dienen ausschließlich zu Informationszwecken und stellen keine Finanzberatung dar. Investitionen in Kryptowährungen sind mit einem hohen Risiko verbunden. Führe immer deine eigene Recherche durch.

Core Lightning Sicherheitslücke: Was Node-Betreiber jetzt tun müssen

Core Lightning hat mehrere bestätigte Sicherheitslücken gemeldet und mit Version 26.06.7 ein Notfall-Update ausgeliefert. Wer einen eigenen Lightning-Node betreibt, aktualisiert jetzt oder startet mit dem Schalter --offline neu.

Physische Münze mit eingeprägtem Bitcoin-Symbol neben einem kleinen Einplatinen-Heimserver mit glühenden Statusleuchten und einem gelösten Netzwerkkabel
12 Min. Lesezeit
Teilen:

Wenn du einen eigenen Lightning-Node mit der Software Core Lightning betreibst, steht heute genau eine Aufgabe an: die Aktualisierung auf Version 26.06.7. Blockstream hat diese Fassung nach eigenen Angaben am 28. August 2026 ausgeliefert, sie schließt mehrere bestätigte Sicherheitslücken, und alle älteren Ausgaben gelten seitdem als nicht mehr unterstützt. Wer nicht sofort aktualisieren kann, startet den Knoten stattdessen mit dem Schalter --offline neu. Beides zusammen dauert wenige Minuten, und beides ist wirksamer als die Reaktion, die vielen zuerst einfällt: den Rechner auszuschalten.

Wenn du Bitcoin dagegen auf einer Börse, in einer gewöhnlichen Wallet oder in einer App liegen hast, ohne selbst einen Knoten zu betreiben, betrifft dich die Warnung nicht unmittelbar. Gemeint ist die Maschine, die deine Zahlungskanäle führt. Wer keine betreibt, hat auch nichts zu aktualisieren. Trotzdem lohnt der Blick: Der Vorgang zeigt, wie schnell aus einem gemeldeten Programmierfehler eine Frist mit Datum wird, und er wiederholt sich gerade in kurzen Abständen.

Was ist passiert: Core Lightning bestätigt Schwachstellen und liefert ein Notfall-Update

Core Lightning, kurz CLN, ist eine von mehreren Programmversionen des Lightning-Netzwerks. Das Lightning-Netzwerk ist eine zweite Schicht über der Bitcoin-Blockchain: Zwei Beteiligte sperren gemeinsam einen Betrag in einer Transaktion und rechnen danach beliebig oft untereinander ab, ohne jede Zahlung einzeln in die Blockchain zu schreiben. Diese gesperrte Verbindung heißt Zahlungskanal. Die Software, die einen solchen Kanal führt, überwacht und im Streitfall verteidigt, heißt Node oder Knoten.

Ende August meldete das CLN-Team öffentlich, es habe über Wochen eine ungewöhnlich hohe Zahl von Schwachstellenmeldungen bearbeitet, die mit Hilfe von KI-Werkzeugen erzeugt worden waren. Mehrere davon erwiesen sich als echt. Die Handlungsanweisung des Projekts auf seinem eigenen Kanal war knapp und lief der ersten Eingebung zuwider: den Knoten auf keinen Fall abschalten, stattdessen mit --offline neu starten, weil dieser Schalter Verbindungen zu anderen Knoten unterbindet und damit den Angriffsweg schließt.

Über den genauen Ablauf gehen die Darstellungen auseinander, und das ist erwähnenswert, weil daran die Bewertung hängt, wie lange die Lücken offen standen. Der Branchendienst CryptoSlate datiert den Eingang der ersten KI-erzeugten Meldungen auf den 13. August und eine erste Ankündigung des Projekts auf den 23. August. Andere Berichte, darunter der von TFTC, setzen die öffentliche Warnung auf den 26. August und sprechen von rund zehn Tagen Vorlauf. Belegt und unstrittig ist das Ende dieser Kette: Am 28. August lag die reparierte Fassung als signierte Programmdatei vor.

Verluste sind bisher nicht gemeldet

Nach dem Stand der Berichterstattung zum Zeitpunkt der Offenlegung gab es keine bestätigten Geldverluste und keinen bekannten Fall, in dem jemand eine der Lücken tatsächlich ausgenutzt hätte. Das ist eine Momentaufnahme und keine Entwarnung: Der technische Kern der Fehler ist bis Mitte September unter Verschluss, und erst danach lässt sich unabhängig prüfen, wie groß das Fenster wirklich war.

Bin ich betroffen? Die Antwort hängt daran, wer deinen Knoten betreibt

Die Warnung gilt der Software Core Lightning. Andere Programmversionen des Lightning-Netzwerks werden in der Mitteilung des Projekts nicht genannt. Für dich lässt sich die Frage entlang einer einfachen Linie beantworten:

  • Du betreibst einen eigenen Knoten mit Core Lightning, etwa auf einem kleinen Heimserver, einem gemieteten Rechner oder einem Fertigpaket wie Umbrel oder Start9: Du bist gemeint. Aktualisieren oder --offline, heute.
  • Du betreibst einen eigenen Knoten mit einer anderen Programmversion: Diese Warnung spricht dich nicht an. Eine allgemeine Aktualisierungsdisziplin bleibt trotzdem sinnvoll, weil Meldungen dieser Art derzeit in kurzen Abständen kommen.
  • Du nutzt eine Lightning-Wallet auf dem Handy, deren Knoten jemand anderes betreibt: Dann liegt die Pflicht zur Aktualisierung bei diesem Anbieter, nicht bei dir. Du erkennst solche Angebote daran, dass du nie eine Software aktualisierst und nie eine Kanalöffnung selbst bezahlst. Welche Wallet welchen Weg geht, sortiert unser Vergleich der Software-Wallets.
  • Du hältst Bitcoin nur auf einer Börse oder auf einem Hardware-Gerät, ohne Lightning zu nutzen: Der Vorgang berührt dein Guthaben nicht.

Diese Unterscheidung ist wichtiger, als sie klingt. Warnungen dieser Art werden schnell zu Meldungen über das gesamte Lightning-Netzwerk verkürzt. Der Adressatenkreis ist enger: Er umfasst die Betreiber einer bestimmten Software in einer bestimmten Ausgabe.

Version 26.06.7: Warum ältere Ausgaben nicht mehr unterstützt sind

Die reparierte Fassung trägt die Nummer 26.06.7. Der Hinweis des Projekts dazu ist kurz und hart: Ausgaben vor 26.06.7 sind nicht mehr unterstützt. Das bedeutet nicht, dass ein älterer Knoten stehenbleibt, denn er läuft technisch weiter. Es bedeutet, dass für diese Stände keine Sicherheitsreparaturen mehr kommen und dass ein bekannter Angriffsweg offen bleibt, sobald der Quelltext veröffentlicht ist.

Beim Datum lohnt Genauigkeit, weil die Angaben leicht auseinandergehen: Der Blogeintrag von Blockstream ist auf den 28. August 2026 datiert, im Umbrel-App-Store trägt dieselbe Fassung den 29. August. Der Unterschied erklärt sich aus dem Weg über die Paketquellen und ändert nichts an der Sache. Wichtig ist die Nummer, nicht der Tag.

Die nächste reguläre Ausgabe mit der Nummer 26.09 ist laut Projekt weiterhin für Ende September geplant. Wer jetzt auf 26.06.7 geht, muss also in wenigen Wochen ohnehin erneut ran. Das spricht dafür, den Weg zur Aktualisierung einmal sauber einzurichten, statt ihn jedes Mal neu zu suchen.

Messingstempel auf frisch gepresstem rotem Wachs, daneben eine Münze mit Bitcoin-Symbol im Schatten
Die Prüfung der Signatur ist der einzige Beleg dafür, dass die heruntergeladene Datei wirklich vom Projekt stammt.

Signatur prüfen: So stellst du fest, dass die Programmdatei vom Projekt stammt

Die Anweisung des Projekts lautet wörtlich übersetzt: Signaturen der Programmdateien prüfen, installieren, neu starten. Diese Reihenfolge ist kein Beiwerk. Eine Signatur ist eine kryptografische Unterschrift, mit der die Entwickler bestätigen, dass eine Datei unverändert von ihnen kommt. Ohne diese Prüfung wäre eine Sicherheitsaktualisierung der ideale Köder: Der Nutzer erwartet eine neue Datei, sucht sie aktiv und installiert sie mit erhöhten Rechten.

Der Grund ist in diesem Fall besonders handfest. Weil der Quelltext zurückgehalten wird, kann in den ersten zwei Wochen niemand nachvollziehen, was in der Datei steckt. Die Unterschrift ist damit vorübergehend der einzige Anhaltspunkt für die Herkunft. Wer über ein Fertigpaket aktualisiert, lädt nicht selbst herunter und überlässt diese Prüfung dem Paketanbieter, was die Aufgabe verschiebt, aber nicht aufhebt.

Der zweite Prüfschritt kommt später

Sobald der Quelltext offenliegt, lässt sich die Software daraus neu bauen und mit der Datei vergleichen, die zwei Wochen lang gelaufen ist. Stimmen beide überein, ist nachträglich belegt, dass in der signierten Datei nichts anderes steckte als das, was das Projekt veröffentlicht hat. Diesen zweiten Schritt kann jeder gehen, und genau darauf beruht die Zusage des Projekts.

Krypto sicher verwahren: Hardware-Wallets im VergleichKrypto sicher verwahren: Hardware-Wallets im Vergleich

Was der Schalter --offline an einem Lightning-Node wirklich abschaltet

Der Schalter --offline ist eine Startoption der Knotensoftware. Das Projekt beschreibt seine Wirkung so: Er beseitigt den Angriffsweg, indem er Angreifern die Möglichkeit nimmt, den Knoten überhaupt anzusprechen, während das Programm weiterläuft und die Blockchain mitliest, um Betrugsversuche zu erkennen.

In der Praxis heißt das: Der Knoten nimmt keine Verbindungen von aussen mehr an und baut selbst keine auf. Zahlungen kannst du weder senden noch empfangen, und geleitete Zahlungen anderer laufen nicht mehr über dich. Alles, was auf der Blockchain passiert, sieht dein Knoten dagegen weiter, und er kann darauf reagieren.

Der Preis ist also klar benannt: Die Verfügbarkeit deiner Kanäle endet, solange der Schalter gesetzt ist. Für einen privaten Knoten ist das eine Unbequemlichkeit. Für einen Knoten, über den regelmäßig fremde Zahlungen laufen, ist es ein Einnahmeausfall. CryptoSlate weist darauf hin, dass genügend verspätete Aktualisierungen und abgeschaltete Knoten die Leitfähigkeit in Teilen des Netzes spürbar senken können.

Warum das Abschalten des Rechners schlechter ist als der Offline-Modus

Hier liegt der Punkt, an dem gut gemeinte Ratschläge Schaden anrichten. Die naheliegende Reaktion auf eine Sicherheitswarnung lautet: Gerät aus. Bei einem Lightning-Knoten ist das die schlechtere von zwei Möglichkeiten, und der Grund liegt in der Bauweise der Zahlungskanäle.

Ein Zahlungskanal wird durch den letzten gemeinsam unterschriebenen Kontostand abgesichert. Jede Seite kann den Kanal jederzeit einseitig über die Blockchain schließen, das heißt Force Close. Wenn eine Gegenseite dabei einen alten, für sie günstigeren Stand einreicht, ist das ein Betrugsversuch. Dagegen schützt eine Einspruchsfrist: Innerhalb eines vereinbarten Zeitfensters darf die geschädigte Seite eine Strafzahlung einreichen und bekommt in diesem Fall den gesamten Kanalinhalt.

Diese Frist läuft in Blockzeit, nicht in Kalenderzeit, und sie läuft unabhängig davon, ob dein Rechner an ist. Ein ausgeschalteter Knoten liest die Blockchain nicht mit, bemerkt den Betrugsversuch nicht und versäumt die Frist. Genau das meint das Projekt mit dem Satz, ein abgeschalteter Knoten könne das nicht leisten. Der Offline-Modus dagegen lässt das Programm laufen und die Kette lesen und nimmt nur die Verbindungen weg.

Wer eine Watchtower nutzt, hat einen Puffer

Eine Watchtower ist ein Wachdienst, der stellvertretend die Blockchain beobachtet und im Betrugsfall die Strafzahlung einreicht, während der eigene Knoten schläft. Wer einen solchen Dienst eingerichtet hat, steht bei einer Auszeit besser da. Verlassen solltest du dich darauf nicht, denn viele private Knoten laufen ohne, und die Einrichtung ist kein Nebenbei-Schritt.

Umbrel und Start9: Wie das Sicherheitsupdate bei Ein-Klick-Knoten ankommt

Viele private Knoten laufen über Fertigpakete mit einer Oberfläche statt über die Kommandozeile. Dort findest du --offline nicht als Knopf im Dashboard; es ist eine Startoption der Anwendung. Deshalb hat der Weg über den App-Store hier eine eigene Geschichte, die sich am Umbrel-Eintrag gut nachlesen lässt.

Dort erschien am 27. August zunächst eine Zwischenfassung mit der Nummer 26.06.6-patch.1. Ihr Hinweis erklärte, der Knoten laufe weiter und beobachte die Bitcoin-Blockchain, könne aber vorerst keine Lightning-Zahlungen senden, empfangen oder weiterleiten. Die Aufforderung dazu war deutlich: Core Lightning laufen lassen und nicht entfernen, die nächste Aktualisierung erscheine wie gewohnt, sobald die Reparatur bereitstehe.

Am 29. August folgte dann 26.06.7 mit dem Hinweis, dies sei eine wichtige Sicherheitsaktualisierung und der Knoten verbinde sich danach automatisch wieder mit dem Lightning-Netzwerk. Für Nutzer solcher Pakete heißt das zweierlei: Der Offline-Modus kam womöglich schon automatisch, ohne dass jemand einen Schalter umgelegt hat. Und die volle Funktion kehrt erst mit der zweiten Aktualisierung zurück. Wer sich seit ein paar Tagen wundert, warum eine Zahlung nicht durchgeht, findet hier die Erklärung.

Gläserne Sanduhr mit rieselndem Sand vor einer verschlossenen Metallkassette mit Vorhängeschloss, davor eine hochkant stehende Münze mit Bitcoin-Symbol
Bis zur Offenlegung des Quelltextes bleibt der technische Kern der Lücken unter Verschluss.

Quelltext erst am 11. September: Was hinter dem Embargo steckt

Ein Embargo ist in diesem Zusammenhang eine vereinbarte Sperrfrist, innerhalb derer technische Einzelheiten einer Schwachstelle nicht veröffentlicht werden. Üblich ist das zwischen Melder und Hersteller vor der Reparatur. Hier liegt der Fall anders: Die Reparatur ist bereits ausgeliefert, und trotzdem bleibt der Quelltext bis zum 11. September 2026 unter Verschluss, also vierzehn Tage nach der Auslieferung.

Die Begründung ist praktisch. Aus einer veröffentlichten Reparatur lässt sich der Fehler zurückrechnen, den sie behebt. Wer den Quelltext hat, sieht, welche Zeilen sich geändert haben, und weiss damit oft schneller als der Verteidiger, wo der Angriff ansetzt. Der Bericht von TFTC schreibt diese Begründung dem CLN-Hauptentwickler Christian Decker zu: Die technischen Einzelheiten würden gerade deshalb zurückgehalten, um Angreifer daran zu hindern, aus ihnen einen funktionierenden Angriff zu bauen.

Dagegen lässt sich einwenden, dass quelloffene Software ihre Überprüfbarkeit gerade daraus bezieht, dass jeder mitlesen kann. Zwei Wochen lang läuft auf den Knoten eine Datei, deren Inhalt niemand ausserhalb des Projekts nachvollziehen kann. Beide Seiten haben ein Argument, und beide beziehen sich auf denselben Zeitraum. Auflösen lässt sich der Streit erst nach dem 11. September, wenn der Vergleich zwischen Quelltext und ausgelieferter Datei möglich wird.

Die Marktlage jeden MorgenDie Marktlage jeden Morgen

KI-erzeugte Schwachstellenmeldungen: das Muster hinter dem Notfall

Der Auslöser dieses Vorgangs ist so bemerkenswert wie sein Verlauf. Die Fehler stammen nicht aus einer geplanten Prüfung. Herein kamen sie als Flut von Meldungen, die mit KI-Werkzeugen erzeugt worden waren. Ein Teil davon war Ausschuss, ein Teil war echt, und die Unterscheidung kostete das Projekt Wochen.

Für freiwillig gepflegte Software ist das eine neue Belastung. Wer Meldungen erhält, muss jede einzelne prüfen, denn ein übersehener echter Fund wäre der teuerste Fehler. Gleichzeitig sinkt der Aufwand auf der Seite derer, die solche Meldungen erzeugen, gegen null. Das Verhältnis zwischen Angriff und Verteidigung verschiebt sich damit spürbar.

Ein Einzelfall ist Core Lightning dabei nicht. TFTC ordnet den Vorgang in eine Reihe ein und nennt als früheres Beispiel den 3. August, an dem der Tauschdienst Boltz seine Swaps unter Verweis auf KI-gestützte Angriffe aussetzte. Wer die vergangenen Wochen verfolgt hat, kennt das Muster auch aus der Hardware-Ecke: Wir haben zuletzt beschrieben, wie BitBox02 mit Firmware 9.26.5 drei Sicherheitslücken schloss und warum bei Coldcard nach einem Firmware-Update der alte Seed nicht in jedem Fall weiterverwendet werden sollte. Die Frage, wie schnell du ein Sicherheitsupdate einspielst, ist damit vom Randthema zur Routine geworden.

Was der Vorfall für deine Bitcoin-Verwahrung bedeutet

Aus einem Vorgang wie diesem folgt nicht, dass Selbstverwahrung ein Fehler wäre. Es folgt eine Einteilung, die sich unabhängig von diesem Fall lohnt: Ein Lightning-Knoten ist ein Gerät, das dauerhaft am Netz hängt, Verbindungen von Fremden annimmt und Schlüssel im laufenden Betrieb braucht. Ein solches System bleibt ein warmes System, egal wie sorgfältig es gepflegt wird.

Daraus ergibt sich eine schlichte Aufteilung deiner Bestände. In den Zahlungskanal gehört der Betrag, den du für Zahlungen tatsächlich brauchst. Alles darüber hinaus gehört auf eine Verwahrung, deren Schlüssel nie an einem Rechner mit Netzverbindung liegen, wie sie unser Vergleich der Hardware-Wallets beschreibt. Die dazugehörige Hausaufgabe ist die Sicherung der Wiederherstellungswörter, zu der wir zusammengetragen haben, was Stahl, Passphrase und Multisig wirklich leisten.

Der zweite Schluss betrifft die Geschwindigkeit. Zwischen der Warnung und der reparierten Fassung lagen nach den vorliegenden Angaben rund zwei Tage. Wer in dieser Zeit nichts von der Warnung mitbekommt, weil er weder dem Projekt folgt noch seine Paketquelle im Blick hat, fällt aus dem Zeitfenster heraus. Ein eingerichteter Benachrichtigungsweg gehört bei selbst betriebener Infrastruktur zur Ausrüstung und nicht zum Komfort.

Core-Lightning-Schwachstelle prüfen: Was du daraus mitnimmst

  1. Prüfe heute die Version deines Knotens und aktualisiere auf 26.06.7. Geht das nicht sofort, starte mit --offline neu und hole die Aktualisierung nach. Wenn du gar nicht sicher bist, welche Software hinter deiner Lightning-Zahlung steckt, klärt das der Vergleich der Software-Wallets.
  2. Trenne heiße und kalte Bestände sauber. Im Kanal bleibt, was du für Zahlungen brauchst, der Rest wandert auf eine Verwahrung ohne dauerhafte Netzverbindung. Welche Geräte das leisten, steht im Hardware-Wallet-Vergleich.
  3. Setz dir den 11. September auf die Liste. An diesem Tag wird der Quelltext veröffentlicht, erst dann lässt sich die gelaufene Datei nachprüfen und die Tragweite der Lücken einordnen. Werkzeuge, mit denen du Bestände und Ereignisse im Blick behältst, sammelt unsere Übersicht der Analyse-Plattformen.

Die belastbaren Belege stehen in der Mitteilung des Projekts zur Fassung 26.06.7 (Blockstream, 28. August 2026) und im Eintrag des Umbrel-App-Stores mit den Hinweisen zu beiden Aktualisierungen (Umbrel App Store).

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

Transparenzhinweis: Dieser Beitrag wurde unter Zuhilfenahme künstlicher Intelligenz erstellt und vor der Veröffentlichung redaktionell geprüft. Alle Zahlen und Angaben wurden gegen die im Text verlinkten Primärquellen abgeglichen. Das Beitragsbild wurde mit KI erzeugt.

Vielleicht auch interessant