Bitcoin Core legt Schwachstellen offen, die Mining und Tor betrafen
📋 Zusammenfassung
Bitcoin Core hat drei seit Oktober 2025 behobene Schwachstellen offengelegt. Dazu gehörte eine schwerwiegende Sicherheitslücke, die das Erstellen von Blöcken durch Mining-Nodes verhindern konnte. Zwei weitere Probleme betrafen die Verarbeitung von Blöcken und die Berechtigungen für Verbindungen über Tor. Betreiber aktueller Versionen sind bereits geschützt.
Bitcoin Core hat drei Sicherheitsprobleme öffentlich gemacht, die im Oktober 2025 behoben worden waren. Das schwerwiegendste konnte dazu führen, dass ein Mining-Node nach einer Reorganisation der Blockchain keine gültigen Blöcke mehr erstellen konnte. Um den Betrieb wiederherzustellen, musste die Software neu gestartet werden.
Die Schwachstellen wurden am 10. November detailliert beschrieben, nachdem der Support für die letzte anfällige Versionsreihe ausgelaufen war. Es gibt keine öffentlichen Berichte über Ausnutzung, den Verlust von Geldern oder Verstöße gegen die Konsensregeln von Bitcoin. Die Offenlegung ist dennoch für Miner und Node-Betreiber relevant, die ältere Client-Versionen verwenden.
Schwerwiegende Schwachstelle betraf Mining-Nodes
Die schwerwiegendste Sicherheitslücke, CVE-2025-62861, betraf die Bitcoin-Core-Versionen 28.0 bis 28.2 sowie 29.0 bis 29.1. Das Problem trat in einer bestimmten Situation auf: Wenn bei einer Reorganisation der Blockchain Transaktionen aus verworfenen Blöcken zurück in den Mempool gelangten, also in die Warteschlange noch unbestätigter Transaktionen.
Dabei konnte eine auf TRUC-Transaktionen angewandte Regel – auch Transaktionen der Version 3 genannt – eine Transaktion entfernen und zugleich andere Transaktionen im Mempool belassen, die von ihr abhingen. Dadurch entstand ein inkonsistenter Zustand. Für Miner bedeutete das, dass das vom Node erstellte Blockmodell die eigene Gültigkeitsprüfung nicht bestand.
Der betroffene Node funktionierte nach einem Neustart wieder normal, da der Mempool dabei in einem konsistenten Zustand neu geladen wurde. Die Korrektur verhindert nun, dass die Regel zur „Sibling Eviction“ während der Wiedereinfügung von Transaktionen nach einer Reorganisation angewendet wird.
📋 Zusammenfassung
Bitcoin Core hat drei seit Oktober 2025 behobene Schwachstellen offengelegt. Dazu gehörte eine schwerwiegende Sicherheitslücke, die das Erstellen von Blöcken durch Mining-Nodes verhindern konnte. Zwei weitere Probleme betrafen die Verarbeitung von Blöcken und die Berechtigungen für Verbindungen über Tor. Betreiber aktueller Versionen sind bereits geschützt.
Bitcoin Core hat drei Sicherheitsprobleme öffentlich gemacht, die im Oktober 2025 behoben worden waren. Das schwerwiegendste konnte dazu führen, dass ein Mining-Node nach einer Reorganisation der Blockchain keine gültigen Blöcke mehr erstellen konnte. Um den Betrieb wiederherzustellen, musste die Software neu gestartet werden.
Die Schwachstellen wurden am 10. November detailliert beschrieben, nachdem der Support für die letzte anfällige Versionsreihe ausgelaufen war. Es gibt keine öffentlichen Berichte über Ausnutzung, den Verlust von Geldern oder Verstöße gegen die Konsensregeln von Bitcoin. Die Offenlegung ist dennoch für Miner und Node-Betreiber relevant, die ältere Client-Versionen verwenden.
Schwerwiegende Schwachstelle betraf Mining-Nodes
Die schwerwiegendste Sicherheitslücke, CVE-2025-62861, betraf die Bitcoin-Core-Versionen 28.0 bis 28.2 sowie 29.0 bis 29.1. Das Problem trat in einer bestimmten Situation auf: Wenn bei einer Reorganisation der Blockchain Transaktionen aus verworfenen Blöcken zurück in den Mempool gelangten, also in die Warteschlange noch unbestätigter Transaktionen.
Dabei konnte eine auf TRUC-Transaktionen angewandte Regel – auch Transaktionen der Version 3 genannt – eine Transaktion entfernen und zugleich andere Transaktionen im Mempool belassen, die von ihr abhingen. Dadurch entstand ein inkonsistenter Zustand. Für Miner bedeutete das, dass das vom Node erstellte Blockmodell die eigene Gültigkeitsprüfung nicht bestand.
Der betroffene Node funktionierte nach einem Neustart wieder normal, da der Mempool dabei in einem konsistenten Zustand neu geladen wurde. Die Korrektur verhindert nun, dass die Regel zur „Sibling Eviction“ während der Wiedereinfügung von Transaktionen nach einer Reorganisation angewendet wird.