Drei Sicherheitslücken in Bitcoin Core: Was du jetzt tun kannst

Bitcoin Core hat am 28. Oktober 2026 drei Sicherheitshinweise auf einmal veröffentlicht. Der schwerwiegendste erlaubt es einer einzigen bösartigen Gegenstelle, jeden Knoten unter Windows, macOS oder BSD zum Absturz zu bringen. Behoben sind alle drei Punkte in den Versionen 29.5, 30.4, 31.2 und 32.1. Wer einen eigenen Bitcoin-Knoten betreibt und seit Montag nicht aktualisiert hat, läuft auf einem Stand, dessen Schwächen seit Mittwoch öffentlich beschrieben sind.

Ein Knoten ist der Rechner, der die gesamte Blockchain selbst prüft, statt einem Anbieter zu glauben. Fällt er aus, verschwindet kein Guthaben: Die Schlüssel liegen in der Wallet, nicht im Knoten. Verloren geht die eigene Prüfung, und bei zwei der drei Fehler geht der Rechner darunter mit in die Knie.

Drei Hinweise an einem Tag: Was Bitcoin Core offengelegt hat

Die drei Veröffentlichungen stehen zusammen in der Hinweisliste des Projekts. Zwei davon sind als „Medium“ eingestuft, einer als „Low“, und alle drei tragen den Zusatz „easily discoverable“, also leicht auffindbar. Das ist die entscheidende Einstufung: Wer den Code liest, findet die Stelle ohne besondere Mühe.

• TCP-Urgent-Daten: Eine Gegenstelle kann einen Knoten unter Windows, macOS oder BSD zum Absturz bringen. Linux ist nicht betroffen.
• Pausierte Pre-BIP31-Gegenstellen: Der Speicherbedarf eines Knotens wächst langsam, aber ohne Grenze.
• Überlauf der Undo-Dateien: Ein Miner kann die Wiederherstellungsdaten anderer Knoten beschädigen.

Die Reihenfolge der Veröffentlichungen ist ungewöhnlich eng getaktet. Die Korrekturen wurden am 26. Oktober eingepflegt und auf die Zweige 29, 30, 31 und 32 zurückportiert. Am 27. Oktober erschienen die Versionen 31.2 und 32.1, am 28. Oktober folgten 29.5 und 30.4, und am selben Tag ging die Beschreibung der Fehler online.

TCP-Urgent-Daten: Warum Windows- und macOS-Knoten abstürzen

Bitcoin Core begrenzt, wie viele Daten es je Gegenstelle zur Verarbeitung vorhält. Wird die Warteschlange zu lang, pausiert die Software das Lesen von diesem Anschluss. Dieser Mechanismus heißt Backpressure: Die Software bremst die Gegenstelle aus, statt selbst vollzulaufen.

Genau diese Bremse lässt sich umgehen. Auf Systemen außerhalb von Linux überwacht Bitcoin Core die Netzwerkanschlüsse mit einer älteren Technik, die auch auf sogenannte Ausnahmezustände eines Anschlusses reagiert. Sie tat das bisher auch dann, wenn das Lesen längst pausiert war. Eine Gegenstelle muss also nur TCP-Urgent-Daten schicken, eine selten genutzte Form der Übertragung außerhalb der normalen Reihenfolge, und der Knoten liest weiter. Die Warteschlange wächst ohne Begrenzung, bis der Arbeitsspeicher voll ist.

Das Projekt beschreibt die Folge in seinem Hinweis unmissverständlich: Eine bösartige Gegenstelle kann auf diesem Weg jeden verbundenen Knoten unter Windows, macOS oder BSD zum Absturz bringen. Kein Vorlauf, keine Vorbereitung, keine Rechenleistung. Gemeldet wurde die Lücke am 23. Oktober, der Fehler war drei Tage später behoben.

Backpressure: die Bremse, die hier versagt

Warum das überhaupt möglich war, liegt an einer Besonderheit der Umsetzung. Unter Linux benutzt Bitcoin Core ein anderes Verfahren, um Netzwerkanschlüsse zu überwachen. Der fehlerhafte Pfad existiert dort schlicht nicht. Deshalb bleiben Knoten auf Linux-Servern, auf den meisten fertigen Knoten-Kästen für zu Hause und in Rechenzentren von diesem Punkt unberührt.

select() statt poll(): Linux-Knoten sind nicht betroffen

Für die Praxis in Deutschland ist das die wichtigste Unterscheidung des ganzen Tages. Wer seinen Knoten auf einem Einplatinenrechner oder einem kleinen Linux-Server laufen lässt, ist bei diesem Fehler außen vor. Wer Bitcoin Core dagegen als Programm auf dem Arbeitsrechner betreibt, also unter Windows oder auf einem Mac, gehört zur betroffenen Gruppe. Dasselbe gilt für Knoten auf BSD-Systemen.

Das ist kein theoretischer Unterschied. Ein abgestürzter Knoten synchronisiert nicht weiter, beantwortet keine Anfragen der eigenen Wallet und meldet keine eingehenden Zahlungen. Wer seine Wallet gegen den eigenen Knoten laufen lässt, sieht in dieser Zeit einen veralteten Kontostand.

Pre-BIP31-Gegenstellen: 2 MB Speicher je Stunde und Verbindung

Der zweite Fehler wirkt langsamer und ist deshalb tückischer. Bitcoin Core legt Ankündigungen für alle Gegenstellen in die Warteschlange, auch für die bereits pausierten. Dazu gehören vor allem die häufigen Hinweise auf neue Transaktionen.

Normalerweise ist das harmlos, weil eine Gegenstelle getrennt wird, wenn sie zwanzig Minuten lang nicht auf eine Prüfnachricht antwortet. Diese Prüfnachricht ist in BIP 31 beschrieben, einem Verbesserungsvorschlag aus der Frühzeit des Netzwerks, der der Ping-Nachricht eine Zufallszahl mitgibt. Gegenstellen, die BIP 31 nicht unterstützen, werden von dieser Trennung ausgenommen. Eine Gegenstelle muss sich also nur alt stellen und das Lesen gezielt verzögern.

Das Projekt beziffert den Zuwachs genau: bis zu 2 MB je Stunde und eingehender Verbindung, bis zu 5 MB je Stunde und ausgehender Verbindung. Ein Knoten mit vielen eingehenden Verbindungen sammelt auf diesem Weg über Tage genug Ballast, um den Arbeitsspeicher zu füllen. Deutlich weniger betroffen sind Knoten, die mit der Einstellung -blocksonly laufen, weil dort die Transaktionsmeldungen wegfallen, die den Großteil der Warteschlange ausmachen.

Gemeldet wurde dieser Punkt bereits am 15. September 2026. Zwischen Meldung und Korrektur lagen also gut sechs Wochen, in denen die Lücke dem Projekt bekannt war und der Öffentlichkeit nicht.

Undo-Dateien über 4 GiB: der dritte Fehler im rev-Verzeichnis

Der dritte Punkt betrifft eine Datei, von der die meisten Knotenbetreiber noch nie gehört haben. Neben den Blockdateien legt Bitcoin Core sogenannte Undo-Dateien an, erkennbar am Namensmuster rev*.dat. Darin steht, welche Münzen ein Block ausgegeben hat. Die Software braucht diese Angaben, wenn eine Reorganisation der Blockchain einen bereits verbuchten Block wieder lösen muss.

Eine Reorganisation, kurz Reorg, ist der Vorgang, bei dem das Netzwerk auf eine andere, längere Kette von Blöcken umschwenkt und zuvor gültige Blöcke zurücknimmt. Blockdateien sind bei 128 MiB gedeckelt, die Undo-Dateien dagegen hatten nie eine Obergrenze. Die Positionen darin wurden als 32-Bit-Zahlen gespeichert, und die reichen nur bis 4 GiB.

Ein Miner kann gültige Blöcke bauen, deren Undo-Daten deutlich größer sind als die Blöcke selbst. Wächst eine Undo-Datei über diese 4 GiB hinaus, springt die Positionsangabe zurück an den Anfang. Neuere Undo-Daten überschreiben ältere, und die Datei wird auf die zurückgesprungene Länge gekürzt. Trennt eine spätere Reorganisation einen betroffenen Block, kann der Knoten dessen Undo-Daten nicht mehr lesen und fährt herunter. Ein Neustart hilft nicht. Die Wiederherstellung verlangt einen vollständigen Neuaufbau des Index mit einer korrigierten Version, auf einem gewöhnlichen Heimrechner eine Sache von Stunden bis Tagen.

32-Bit-Systeme und FAT32 bleiben auch nach dem Update verwundbar

Hier liegt der Punkt, der im Gegensatz zu den beiden anderen nicht vollständig erledigt ist. Behoben wurde der Überlauf, indem die Positionen nun als 64-Bit-Zahlen gespeichert werden und Windows die passenden Dateibefehle benutzt. Das Format auf der Festplatte bleibt unverändert, ein Umzug der Daten ist also nicht nötig.

Zwei Konstellationen bleiben trotzdem anfällig. Auf 32-Bit-Systemen arbeiten die Dateibefehle weiterhin nur bis 2 GiB, dort tritt der Fehler also schon bei der Hälfte der Datenmenge auf, und zwar ohne jede Reorganisation. Und wer sein Blockverzeichnis auf einem FAT32-Dateisystem liegen hat, etwa auf einer älteren externen Festplatte oder einem USB-Stick, stößt an die Dateigrenze dieses Formats von 4 GiB. In beiden Fällen scheitert das Schreiben der Undo-Daten, und der Knoten fährt bei jedem Start erneut herunter.

Praktisch ausnutzen lässt sich der Fehler auf 64-Bit-Systemen kaum. Das Projekt beschreibt den Aufwand im Detail: Die nötigen Transaktionen sind nicht standardkonform, ein Angreifer müsste mehrere tausend solcher Blöcke schürfen, was etwa einem Monat der Blockproduktion des gesamten Netzwerks entspricht, und danach müssten rund achtzehn weitere seiner Blöcke genau am Ende einer Blockdatei des Zielknotens landen. Zuletzt müsste er eine Reorganisation über zwei Blöcke gewinnen. Da die Dateiaufteilung von Knoten zu Knoten verschieden ist, trifft keine Vorbereitung alle Ziele.

Project Loupe: Ein automatischer Scan fand alle drei Lücken

Alle drei Fehler gehen auf dieselbe Quelle zurück. Sie wurden durch einen automatisierten Scan mit einem Sprachmodell gefunden, der unter dem Namen Project Loupe bei Spiral läuft und von Elias Rohrer verantwortet wird. Gregory Sanders prüfte die Funde und meldete sie an das Sicherheitsteam von Bitcoin Core.

Zwei der drei Punkte wurden unabhängig davon ein zweites Mal entdeckt. Der Entwickler L0rinc meldete den Speicherfehler bei pausierten Gegenstellen am 21. September und den Undo-Überlauf am 21. August, Andrew Dorman den Undo-Überlauf am 23. Oktober. Die Korrekturen stammen jeweils von Antoine Poinsot.

Vom Embargo zur Offenlegung: Bitcoin Core hat die Regeln geändert

Dass die Beschreibungen schon einen Tag nach den fertigen Versionen öffentlich standen, ist kein Zufall. Das Projekt hat seine Veröffentlichungspraxis erst kürzlich umgestellt und die lange Sperrfrist aufgegeben, über die wir am 23. Oktober 2026 berichtet haben: Bitcoin Core kippt das Embargo. Die drei Hinweise vom 28. Oktober sind der erste größere Durchlauf nach der neuen Linie.

Für Betreiber hat das zwei Seiten. Die Lücken sind schneller bekannt, und wer nicht aktualisiert, ist schneller angreifbar. Gleichzeitig steht jetzt in nachlesbarer Form, was genau schiefgehen kann, statt nur eine Versionsnummer mit dem Vermerk „Sicherheitsupdate“.

Ohne eigenen Knoten: Wo dein Bitcoin-Guthaben dann liegt

Der größere Teil der deutschen Anleger betreibt keinen eigenen Knoten. Wer seine Coins in einer Software-Wallet auf dem Handy oder dem Rechner hält, nutzt die Knoten anderer Leute, meist die des Wallet-Anbieters. Welche Wallet welchen Weg wählt und wo du deine eigene Prüfung einschalten kannst, steht im Vergleich der Software-Wallets.

Von den drei Fehlern ist in dieser Gruppe niemand direkt betroffen. Ein Risiko bleibt trotzdem: Fällt der Knoten des Anbieters aus, siehst du keinen aktuellen Kontostand und bekommst keine Zahlung bestätigt. Deine Schlüssel liegen davon unberührt in der Wallet, und das ist der ganze Punkt der Selbstverwahrung.

Der Kurs hat auf die Veröffentlichung nicht reagiert. Bitcoin notierte am Morgen des 29. Oktober 2026 bei rund 79.790 US-Dollar (CoinGecko) und damit etwa 1,6 Prozent unter dem Vortag, im Gleichschritt mit dem übrigen Markt nach dem Zinsentscheid der US-Notenbank vom Vortag.

Bitcoin Core 32.1: Wer auf 32-Bit bleibt, bleibt verwundbar

1. Version prüfen und wechseln. In der Konsole zeigt bitcoin-cli getnetworkinfo die laufende Version. Alles unterhalb von 29.5, 30.4, 31.2 oder 32.1 gehört getauscht, besonders auf Windows und macOS. Wer bei der Gelegenheit die Schlüssel vom Alltagsrechner trennen will, findet die Geräte im Hardware-Wallet-Vergleich.
2. Dateisystem und Architektur ansehen. Liegt das Blockverzeichnis auf FAT32 oder läuft der Knoten auf einem 32-Bit-System, bleibt der dritte Fehler offen. Ein Umzug auf ein modernes Dateisystem beseitigt ihn. Wer stattdessen ganz auf einen Anbieter setzt, vergleicht die Gebühren im Überblick der Krypto-Börsen.
3. Speicherverbrauch beobachten. Wächst der Verbrauch eines älteren Knotens über Tage stetig, passt das zum zweiten Fehler. Mit -blocksonly fällt der Zuwachs deutlich kleiner aus. Wer sein Guthaben lieber bei einem beaufsichtigten Haus hält, prüft die Zulassungen unter den regulierten Krypto-Börsen.

Die vollständigen Beschreibungen stehen in der Hinweisliste von Bitcoin Core, der Text zur TCP-Lücke im zugehörigen Einzelhinweis.

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