Bitcoin Core hat im November 2026 drei Sicherheitslücken offengelegt, die seit rund einem Jahr behoben sind. Die schwerste davon stuft das Projekt als High ein: Sie hinderte Mining-Nodes nach einer Chain-Reorganisation daran, gültige Block-Templates zu erstellen.
Hinter dem Namen steht die Referenzimplementierung des Bitcoin-Protokolls. Mit dieser Open-Source-Software prüfen und verbreiten Nodes im Netzwerk Transaktionen und Blöcke. Miner und Pools nutzen sie zudem, um aus unbestätigten Transaktionen im Mempool, dem Wartebereich des Netzwerks, Block-Templates zu bauen. Schwachstellen legt das Projekt grundsätzlich verzögert offen. Zunächst erscheint der Fix in einem Release, die Beschreibung folgt erst, wenn die betroffenen Versionen veraltet sind. Die Korrekturen verteilten sich auf die Versionen 30.0, 29.2 und 28.3 vom Oktober 2025. Die drei Hinweise tragen die Kennungen CVE-2025-62861 (High) sowie CVE-2025-62859 und CVE-2025-62860 (beide Medium). Veröffentlicht hat das Projekt sie deshalb erst 14 Tage nach dem Support-Ende der Versionslinie 29.x, der letzten verwundbaren.
Abonnieren Sie unseren Newsletter
Die besten Artikel der Woche direkt in ihre Mailbox geliefert.
Wie eine Reorganisation Mining-Nodes lahmlegen konnte
Die High-Lücke CVE-2025-62861 betrifft die Versionen 28.0 bis 28.2 sowie 29.0 bis 29.1. Gemeldet hat sie Niklas Goegge im September 2025. Ihren Ursprung hat sie in TRUC, kurz für Topologically Restricted Until Confirmation, auch als v3-Transaktionen bekannt. Diese Mempool-Policy setzt strikte Grenzen dafür, wie unbestätigte Transaktionen voneinander abhängen dürfen. Sie soll vor allem Layer-2-Protokollen wie dem Lightning-Netzwerk das nachträgliche Erhöhen von Gebühren erleichtern. Mit Version 28.0 kam ausserdem die Regel der Sibling Eviction hinzu. Will eine neue Transaktion einer TRUC-Parent-Transaktion ein zweites Kind hinzufügen und zahlt sie genug Gebühren, ersetzt sie das bestehende Kind.
Der Fehler zeigte sich bei einer Reorganisation (kurz Reorg), bei der das Netzwerk zuletzt angehängte Blöcke durch eine andere Kette ersetzt. Transaktionen aus den getrennten Blöcken legt Bitcoin Core zunächst mit dem Flag `bypass_limits=true` zurück in den Mempool. Der Sibling-Eviction-Zweig war jedoch nicht an dieses Flag gebunden. Er lief trotzdem. Folglich verdrängte die Regel eine Transaktion, während deren Nachfahren im Mempool zurückblieben. Der Mempool enthielt danach Transaktionen, die nicht existierende Outputs ausgeben. Somit schlug die Validitätsprüfung bei der Erstellung neuer Block-Templates fehl.
Betroffene Miner konnten erst nach einem Neustart des Nodes wieder gültige Templates erstellen, weil dieser den Mempool konsistent neu lädt. Eine andere Abhilfe als das Update nennt der Advisory zu CVE-2025-62861 allerdings nicht. Den Fix lieferte Greg Sanders mit PR #33504, der im Oktober 2025 in den Hauptzweig einfloss. Ferner portierte das Projekt ihn auf die Linien 28.x, 29.x und 30.x zurück. Die Lücke traf jedoch nur die Template-Erstellung. Da TRUC eine Mempool-Regel und keine Konsensregel ist, berührte der Fehler den Konsens nicht.
Zwei Medium-Lücken betreffen Block-Relay und Tor-Peers
CVE-2025-62859 betrifft Versionen vor 29.2 und vor 30.0. Eugene Siegel hatte die Schwachstelle bereits im April 2025 gemeldet. Sie steckt im Umgang mit Compact Blocks, einem verkürzten Format, mit dem Nodes neue Blöcke untereinander weitergeben. Betroffene Versionen löschten den Download-Status eines solchen Blocks, bevor sie die Witness-Malleation prüften, also eine nachträgliche Veränderung der Witness-Daten. Schlug diese Prüfung fehl, forderte der Node die Daten per `GETDATA` beim selben Peer erneut an, mit einem Timeout von 10 Minuten. Ein bösartiger Peer, der einen Compact Block zuerst ankündigt, konnte die Blockverarbeitung des Opfers daher um bis zu 10 Minuten verzögern. Unbegrenzt wiederholbar war der Angriff ferner im `-blocksonly`-Modus oder wenn der Angreifer alle drei High-Bandwidth-Peers kontrollierte. Behoben hat den Fehler schliesslich PR #32646, der im Juni 2025 in den Code einfloss.
Die zweite Medium-Lücke, CVE-2025-62860, betrifft Versionen vor 28.3, 29.2 und 30.0. Gemeldet haben sie Martin Zumsande und Antoine Poinsot im September 2025, zwei Wochen vor Goegges Meldung der High-Lücke. Eingehende Tor-Verbindungen erscheinen in Bitcoin Core mit der IP-Adresse des Tor-Daemons, des lokalen Dienstes, der den Verkehr aus dem Anonymisierungsnetz weiterreicht. Lag diese Adresse in einem per `-whitelist` freigegebenen IP-Bereich, erhielten folglich alle eingehenden Tor-Peers Whitelist-Rechte. Diese heben DoS-Limits und Schutzmassnahmen gegen Privacy-Leaks auf. Laut Advisory hatten „Tausende" erreichbare Mainnet-Nodes alle eingehenden Tor-Verbindungen auf diese Weise freigeschaltet. Gesetzt hatten die Einstellung oft Anbieter, die Bitcoin Core zusammen mit einem Tor-Daemon als Paket ausliefern. Nodes ohne die optionale, nicht standardmässige Einstellung waren hingegen nie betroffen. Seit PR #33395 berücksichtigt Bitcoin Core Tor-Inbound-Peers bei der Vergabe von Whitelist-Rechten nicht mehr.
Beide Lücken stuft das Projekt als Medium ein. Die Verzögerung der Blockverarbeitung war befristet und nur in bestimmten Konstellationen beliebig wiederholbar. Für die Tor-Lücke brauchte es dagegen eine Konfiguration, die vom Standard abweicht.
Warum zwischen Fix und Offenlegung ein Jahr verging
Bitcoin Core trennt Fix und Offenlegung bewusst. Die Korrektur erscheint zuerst in einem regulären Release, ohne dass das Projekt die Schwachstelle beschreibt. Details folgen später, sobald die betroffenen Versionen älter sind oder ihr Support-Ende erreicht haben. Betreiber erhalten somit Zeit für das Update. Bei den drei aktuellen Hinweisen gingen die Meldungen zwischen April und September 2025 ein. Die Fixes flossen von Juni bis Oktober 2025 in den Code. Im Oktober 2025 erschienen schliesslich Bitcoin Core 30.0, 29.2 und 28.3 mit den Korrekturen.
Den Zeitpunkt der Offenlegung bestimmte das Support-Ende. Am 27. Oktober 2026 lief die Unterstützung für 29.x aus, die letzte verwundbare Versionslinie. Die Advisories folgten am 10. November 2026, also 14 Tage später. Der Advisory-Index des Projekts kennt ausserdem vier Schweregrade: Critical, High, Medium und Low. Alle drei Hinweise liegen auf den mittleren Stufen. Auffällig ist die Spanne bei CVE-2025-62859. Siegel meldete die Lücke im April 2025, der Fix war im Juni 2025 gemergt. Öffentlich wurde sie dennoch erst gut 18 Monate nach der Meldung.
Was die Sicherheitslücken für Miner und Node-Betreiber bedeuten
Von der High-Lücke waren vor allem Miner und Pools betroffen. Den Fehler lösten nur Nodes aus, die eine Reorg erlebten und danach Block-Templates erstellen mussten. Die beiden Medium-Lücken trafen hingegen auch gewöhnliche Nodes, setzten aber eine bestimmte Netzwerklage oder Konfiguration voraus. Behoben sind alle drei Fehler in 30.0 und 29.2, zwei davon auch in 28.3. Unterstützt sind seit Ende Oktober 2026 jedoch nur noch Versionen ab 30.x. Wer 29.x oder älter betreibt, nutzt daher auch mit den Backports Software ohne Support.
Mehrere Fragen lassen die Advisories offen. Unklar ist etwa, ob ein Angreifer die Reorg-Topologie, die den High-Fehler auslöst, gezielt herbeiführen kann. Ebenso wenig geht aus den Hinweisen hervor, ob jemand eine der drei Lücken je ausgenutzt hat. Für die Tor-Lücke fehlt zudem eine genaue Zahl betroffener Nodes. Belegt ist dagegen, dass alle drei Fehler gut ein Jahr vor ihrer Offenlegung behoben und ausgeliefert waren.
