Tor-Whitelist-Lücke in Bitcoin Core: Tausende Knoten behandelten Fremde als vertraut

Bitcoin Core hat am 10. November 2026 drei weitere Sicherheitslücken offengelegt. Die folgenreichste betrifft Knoten, die Bitcoin Core zusammen mit dem Anonymisierungsdienst Tor betreiben: Wer die Option -whitelist für einen IP-Bereich gesetzt hatte, behandelte bis zu den Versionen 28.3, 29.2 und 30.0 auch jede eingehende Tor-Verbindung als vertrauenswürdige Gegenstelle. Nach Angaben der Entwickler betraf das tausende erreichbare Knoten im Hauptnetz. Alle drei Fehler sind seit über einem Jahr behoben, wer seinen Knoten aktuell hält, ist geschützt. Wer noch eine Version vor 30.0 betreibt, sollte jetzt aktualisieren, denn mit 29.x ist die letzte betroffene Versionsreihe am 27. Oktober aus der Wartung gefallen.

Bitcoin Core ist die Referenzsoftware des Bitcoin-Netzwerks. Ein Knoten (englisch Node) ist ein Rechner, der diese Software ausführt, jeden Block selbst prüft und Transaktionen an andere Knoten weiterreicht. Wer einen eigenen Knoten betreibt, verlässt sich beim Kontostand nicht auf fremde Server. Wie viel Aufwand und Strom das kostet, haben wir in unserem Überblick Bitcoin Node betreiben durchgerechnet.

Bitcoin Core: Drei Offenlegungen am 10. November

Die drei Hinweise tragen die Kennungen CVE-2025-62859, CVE-2025-62860 und CVE-2025-62861. Eine CVE-Nummer (Common Vulnerabilities and Exposures) ist eine weltweit eindeutige Kennung für eine bekannt gewordene Sicherheitslücke. Bitcoin Core stuft zwei der drei Fehler als mittelschwer ein, einen als schwer. Der Ablauf folgt der Offenlegungsregel des Projekts: Eine Lücke wird erst öffentlich beschrieben, wenn die letzte betroffene Versionsreihe keine Wartung mehr bekommt.

Diese Schwelle ist seit dem 27. Oktober 2026 erreicht. Damals endete die Wartung für Bitcoin Core 29.x, nachdem am 27. Oktober Version 32.1 erschienen war. Am 28. Oktober folgten die Wartungsversionen 31.2, 30.4 und 29.5, am selben Tag legte das Projekt bereits drei andere Fehler offen, über die wir in unserem Artikel Drei Sicherheitslücken in Bitcoin Core berichtet haben. Die neuen Hinweise sind die zweite Runde innerhalb von zwei Wochen, sie betreffen aber andere Teile der Software.

Gemeinsam ist allen drei Fällen, dass externe Entwickler die Fehler gefunden und vertraulich an die Sicherheitsliste des Projekts gemeldet haben. Die Korrekturen flossen still in die Versionen 28.3, 29.2 und 30.0 ein, die zwischen dem 10. und dem 20. Oktober 2025 erschienen. Öffentlich beschrieben werden sie erst jetzt, gut ein Jahr später.

Tor-Whitelist: Warum Tor-Verbindungen als vertrauenswürdig galten

Der Fehler mit der Kennung CVE-2025-62860 steckt in einer Einstellung, die viele Heimanwender nie selbst gesetzt haben. Mit -whitelist markiert ein Betreiber bestimmte Gegenstellen als vertrauenswürdig. Für sie hebt Bitcoin Core laut dem Sicherheitshinweis des Projekts verschiedene Grenzen gegen Überlastungsangriffe auf und lockert Schutzmaßnahmen, die verhindern sollen, dass Informationen über den Knoten nach außen dringen. Gedacht ist das für eigene Geräte im Heimnetz, etwa einen zweiten Rechner oder eine Wallet-Software, die direkt mit dem Knoten spricht.

Das Problem entsteht durch die Art, wie Tor Verbindungen zustellt. Ein fremder Rechner, der über Tor einen Knoten erreicht, erscheint aus Sicht von Bitcoin Core nicht mit seiner eigenen Adresse. Sichtbar ist nur die Adresse des Tor-Dienstes, und der läuft meist auf demselben Gerät oder im selben Heimnetz. Lag diese Adresse in dem IP-Bereich, den der Betreiber per -whitelist freigegeben hatte, landete jede eingehende Tor-Verbindung auf der Liste der vertrauten Gegenstellen. Ein beliebiger Teilnehmer aus dem Internet bekam damit dieselben Rechte wie das eigene Gerät im Wohnzimmer.

Behoben ist das in Bitcoin Core 30.0 und allen späteren Versionen sowie ab den Wartungsversionen 28.3 und 29.2. Seitdem erhalten eingehende Tor-Verbindungen, die über eine eigens für Tor eingerichtete Adresse (onion bind) ankommen, nie Whitelist-Rechte. Knoten, die die Option -whitelist nie gesetzt hatten, waren nach Angabe der Entwickler zu keinem Zeitpunkt betroffen.

Gefunden haben die Lücke die Bitcoin-Core-Entwickler Martin Zumsande und Antoine Poinsot. Die beiden meldeten den Fehler am 12. September 2025 an das Sicherheitsteam. Die Korrektur wurde am 17. September 2025 eingespielt und in ältere Versionsreihen übernommen. Am selben Tag informierte Poinsot laut dem Hinweis auch Luke Dashjr, der die alternative Knotensoftware Bitcoin Knots betreut, am 19. September dann mehrere betroffene Softwareanbieter.

Komplettpakete für Heimknoten: Woher die tausenden betroffenen Knoten kamen

Dass die Lücke so breit wirkte, lag an einer Gewohnheit der Branche. Laut dem Sicherheitshinweis haben verbreitete Anbieter Bitcoin Core zusammen mit einem Tor-Dienst ausgeliefert und die Option -whitelist ab Werk auf einen IP-Bereich gesetzt, in dem auch der Tor-Dienst lag. Hinzu kam, dass Zusatzsoftware, die auf Bitcoin Core aufsetzt, die Whitelist-Einstellung für ihren Betrieb voraussetzte. Diese Programme laufen häufig neben einem Tor-Dienst. Das Ergebnis beschreiben die Entwickler so: Tausende erreichbare Knoten im Hauptnetz setzten jede eingehende Tor-Verbindung auf die Whitelist.

Für viele Heimanwender ist das ein bekanntes Bild. Fertige Knotenpakete für kleine Rechner bündeln Bitcoin Core, Tor, einen Server für Wallet-Abfragen und oft auch Lightning-Software unter einer grafischen Oberfläche. Die Einstellungsdatei bekommt der Nutzer selten zu sehen. Ob ein bestimmtes Paket betroffen war, nennt der Hinweis nicht, die Hersteller wurden vor gut einem Jahr informiert. Wer ein solches Paket nutzt, findet die eingesetzte Bitcoin-Core-Version in der Regel in der App-Übersicht oder den Versionshinweisen des Pakets.

Wichtig ist der Unterschied zwischen dem Paket und der darin enthaltenen Bitcoin-Core-Version. Ein Paket kann frisch aktualisiert sein und trotzdem eine ältere Bitcoin-Core-Version mitliefern, wenn die einzelne App nicht nachgezogen wurde. Maßgeblich für die drei Lücken ist allein die Versionsnummer von Bitcoin Core.

CVE-2025-62859: Compact Blocks und das zehnminütige Warten

Die zweite mittelschwere Lücke betrifft die Art, wie Knoten neue Blöcke sparsam austauschen. Compact Blocks sind ein Verfahren, bei dem ein Knoten nicht den ganzen Block überträgt, sondern nur kurze Kennungen der enthaltenen Transaktionen. Der Empfänger setzt den Block aus Transaktionen zusammen, die er ohnehin schon in seinem Zwischenspeicher hält. Das spart Bandbreite und beschleunigt die Verbreitung neuer Blöcke im Netz.

Bitcoin Core vor den Versionen 29.2 und 30.0 räumte nach dem Zusammensetzen eines solchen Blocks seinen Download-Status auf, bevor es auf eine bestimmte Manipulation der Signaturdaten prüfte (Witness Malleation). Schlug diese Prüfung fehl, forderte der Knoten den Block erneut an, und zwar bei derselben Gegenstelle, mit einer Wartezeit von zehn Minuten. Ein Angreifer, der einem Knoten einen neuen Block als Erster ankündigt, konnte so dessen Blockverarbeitung aufhalten.

Wiederholbar ohne Ende war der Angriff unter zwei Bedingungen, die der Hinweis nennt: wenn der Angreifer alle drei Gegenstellen kontrollierte, die der Knoten für die schnelle Blockübertragung nutzt, oder wenn der Knoten im Modus -blocksonly lief, also nur Blöcke und keine losen Transaktionen weiterreicht. Entdeckt hat den Fehler der Entwickler Eugene Siegel, gemeldet am 28. April 2025. Die Korrektur von Gregory Sanders wurde am 30. Juni 2025 übernommen.

Für einen Heimknoten bedeutet ein solcher Stillstand vor allem, dass er neuen Blöcken hinterherläuft. Die Wallet, die an ihm hängt, zeigt dann eingehende Zahlungen später an. Wer Bitcoin empfängt und den Eingang über den eigenen Knoten bestätigt, sieht im schlimmsten Fall einen veralteten Stand.

CVE-2025-62861: TRUC-Transaktionen stoppen Miner nach einer Reorganisation

Die einzige als schwer eingestufte Lücke trifft vor allem Miner. TRUC steht für Topologically Restricted Until Confirmation und bezeichnet Transaktionen der Version 3 nach BIP 431. Für sie gelten bis zur Bestätigung strengere Regeln: höchstens ein unbestätigter Vorgänger und höchstens ein unbestätigter Nachfolger. Diese Regeln gelten nur für den Zwischenspeicher eines Knotens (Mempool), nicht für die Konsensregeln. Ein gültiger Block darf also durchaus anders aufgebaut sein.

Seit Version 28.0 kennt Bitcoin Core eine Ersetzungsregel für diese Transaktionen, die sogenannte Sibling Eviction. Bekommt eine TRUC-Transaktion ein zweites unbestätigtes Kind, verdrängt das neue Kind das alte, wenn es genug Gebühr zahlt. Bei einer Reorganisation, also wenn ein Knoten auf eine längere konkurrierende Blockfolge umschwenkt, legt Bitcoin Core die Transaktionen der verworfenen Blöcke zurück in den Mempool. Dabei lief die Verdrängungsregel fälschlich weiter mit.

Die Folge laut Hinweis: Im Mempool blieben Transaktionen zurück, die Ausgaben verwendeten, die es dort nicht mehr gab. Ein Miner, dessen Knoten eine solche Reorganisation erlebte, konnte keine gültige Blockvorlage mehr erstellen, bis er den Knoten neu startete. Betroffen sind die Versionen 28.0 bis 28.2 und 29.0 bis 29.1, behoben ist der Fehler in Bitcoin Core 30.0 vom 10. Oktober 2025. Gemeldet hat ihn Niklas Gögge am 26. September 2025.

Schweregrad Hoch und Mittel: Die Einstufung der drei Lücken

Bitcoin Core ordnet jede gemeldete Lücke einer von vier Klassen zu, die das Projekt auf seiner Seite zu Sicherheitshinweisen beschreibt. Als kritisch gelten Fehler, die die Sicherheit des gesamten Netzes bedrohen, etwa Diebstahl von Coins auf Protokollebene, das Erzeugen von Coins außerhalb des festgelegten Ausgabeplans oder eine dauerhafte Spaltung des Netzes. Keine der drei neuen Lücken fällt in diese Klasse.

Schwer (High) sind Fehler mit erheblicher Wirkung auf betroffene Knoten oder das Netz, die sich typischerweise aus der Ferne und unter Standardeinstellungen ausnutzen lassen. Mittelschwer (Medium) sind Fehler, die Leistung oder Funktion spürbar mindern, deren Reichweite oder Ausnutzbarkeit aber begrenzt ist. Für die Tor-Lücke heißt das: Der Fehler wirkte nur bei gesetzter Whitelist, dort aber bei sehr vielen Knoten gleichzeitig.

Die Einordnung hilft bei der Frage, wie dringend ein Update ist. Ein Heimknoten, der keine Blöcke erzeugt, ist von der schweren TRUC-Lücke praktisch nicht berührt, denn sie trifft die Erstellung von Blockvorlagen. Für Heimanwender sind die beiden mittelschweren Lücken die wichtigeren, weil sie Datenschutz und Erreichbarkeit des eigenen Knotens betreffen.

Bitcoin Core 29.x am Ende der Wartung: Seit 27. Oktober keine Sicherheitsupdates

Das Projekt wartet nach seiner eigenen Lebenszyklus-Regel immer die drei jüngsten Hauptversionen. Seit Version 32.0 sind das 32.x, 31.x und 30.x. Hauptversionen, die aus diesem Fenster fallen, bekommen in der Regel keine Sicherheitskorrekturen mehr. Aktuell sind die Versionen 32.1 vom 27. Oktober sowie 31.2 und 30.4 vom 28. Oktober 2026.

Wer noch eine 29er-Version betreibt, hat zwar für die drei neuen Lücken mit 29.5 eine korrigierte Fassung zur Verfügung, bekommt aber künftig keine Korrekturen mehr. Der Umstieg auf eine gewartete Hauptversion ist deshalb der sauberere Weg. Vor einem großen Versionssprung lohnt ein Blick in die Versionshinweise, weil sich Standardeinstellungen ändern können.

Die eigene Version zeigt der Befehl bitcoin-cli --version oder die Ausgabe von bitcoin-cli getnetworkinfo im Feld subversion, dort steht etwa /Satoshi:30.4.0/. In der grafischen Oberfläche Bitcoin-Qt findest du die Angabe unter Hilfe und Info. Bei Komplettpaketen steht sie meist in der Übersicht der installierten Apps.

Whitelist-Einstellung in der bitcoin.conf: Welche Zeilen auffallen

Unabhängig von der Version lohnt ein Blick in die Einstellungsdatei bitcoin.conf. Zeilen, die mit whitelist= beginnen, geben Gegenstellen besondere Rechte. Steht dort ein ganzer IP-Bereich, etwa ein Netz des Heimrouters oder eines internen Container-Netzes, solltest du wissen, welche Geräte darin liegen und ob ein Tor-Dienst dazugehört. Wer die Datei nicht selbst angelegt hat, findet sie bei Komplettpaketen oft nur über einen erweiterten Zugang auf den Rechner.

Ab Bitcoin Core 30.0, 29.2 und 28.3 behandelt die Software eingehende Tor-Verbindungen, die über die eigens dafür eingerichtete Adresse ankommen, ohnehin nicht mehr als vertraut. Mit einer aktuellen Version ist der Kern der Lücke also geschlossen, selbst wenn die Whitelist-Zeile unverändert bleibt. Eine knapp gefasste Whitelist bleibt trotzdem gute Praxis, weil jede Ausnahme Schutzgrenzen aufhebt.

Bitcoin-Guthaben und Wallet: Warum die Lücken keine Coins kosten

Die gute Nachricht für Anleger: Keine der drei Lücken erlaubte es nach der Einstufung des Projekts, Coins zu stehlen oder neue zu erzeugen. Die privaten Schlüssel liegen bei den meisten Heimanwendern ohnehin in einer separaten Wallet und gar nicht im Knoten selbst. Wer seine Bestände auf einer Hardware-Wallet verwahrt und den Knoten nur als eigene Prüfinstanz nutzt, trennt Schlüssel und Netzsoftware sauber. Welche Geräte dafür in Frage kommen, zeigt unser Hardware-Wallet-Vergleich.

Die Risiken lagen bei Erreichbarkeit und Datenschutz. Eine Gegenstelle mit Whitelist-Rechten unterliegt weniger Grenzen gegen Überlastung und bekommt Informationen, die der Knoten Fremden sonst vorenthält. Für Nutzer, die Tor gerade wegen der Anonymität einsetzen, ist das der heikelste Punkt. Ein Knoten, der neuen Blöcken hinterherläuft, zeigt zudem Zahlungseingänge verspätet an.

Wer keinen eigenen Knoten betreibt, ist von den drei Lücken nicht direkt betroffen. Software-Wallets auf dem Smartphone fragen in der Regel fremde Server ab, die der Anbieter betreibt, und Börsen verwahren die Coins ihrer Kunden auf eigener Infrastruktur. Einen Überblick über Wallets ohne eigenen Knoten bietet unser Software-Wallet-Vergleich.

Bitcoin-Core-Lücken: Ab Version 30 sind alle drei geschlossen

Die drei Offenlegungen vom 10. November beschreiben Fehler, die seit Oktober 2025 behoben sind. Gefährdet ist, wer einen Knoten mit einer älteren Version betreibt und das Update seit einem Jahr aufschiebt. Drei Schritte reichen:

1. Version prüfen und aktualisieren: Liegt dein Knoten unter 30.0, wechsle auf eine gewartete Hauptversion wie 30.4, 31.2 oder 32.1. Wer seine Coins nur über eine Börse hält, braucht keinen eigenen Knoten; seriöse Anbieter findest du in unserem Vergleich der besten Krypto-Börsen.
2. Whitelist kürzen: Prüfe in der bitcoin.conf jede Zeile mit whitelist= und beschränke sie auf die Geräte, die du wirklich kennst. Für Wallet-Abfragen ohne eigenen Knoten hilft unser Software-Wallet-Vergleich.
3. Schlüssel vom Knoten trennen: Halte größere Bestände auf einer Hardware-Wallet und nutze den Knoten nur zur Prüfung. Passende Geräte zeigt der Hardware-Wallet-Vergleich.

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