Bitcoin Core hat im November 2026 Details zu drei Sicherheitslücken veröffentlicht, rund ein Jahr nachdem die Behebungen für diese Schwachstellen bereits ausgeliefert worden waren. Die schwerwiegendste der drei Lücken, mit der Einstufung High, konnte Mining-Nodes daran hindern, nach einer Chain-Reorganisation gültige Blockvorlagen zu erstellen.

Bitcoin Core ist die Referenzimplementierung des Bitcoin-Protokolls. Nodes im Netzwerk nutzen diese Open-Source-Software, um Transaktionen und Blöcke zu prüfen und weiterzuleiten, während Miner und Mining-Pools damit Blockvorlagen aus unbestätigten Transaktionen im Mempool zusammenstellen, dem Auffangbereich des Netzwerks für ausstehende Transaktionen.

Nach Projektrichtlinie werden Schwachstellen erst mit Verzögerung veröffentlicht: Die Behebung wird zuerst in einem Release ausgeliefert, die technische Beschreibung folgt erst, wenn die betroffenen Versionen veraltet sind. Die Korrekturen für diese Lücken flossen in die Versionen 30.0, 29.2 und 28.3 ein, die alle im Oktober 2025 erschienen. Die Advisories tragen die Kennungen CVE-2025-62861, CVE-2025-62859 und CVE-2025-62860 — die Standardkennungen, unter denen öffentlich bekannt gemachte Software-Sicherheitslücken katalogisiert werden. CVE-2025-62861 ist als High eingestuft; die beiden anderen tragen die Einstufung Medium. Accordingly veröffentlichte das Projekt die Advisories nur 14 Tage nach Ende des Supports für die 29.x-Linie, die letzte anfällige Release-Serie. Die vollständigen Texte sind in der offiziellen Veröffentlichung und im Security-Advisory-Index des Projekts verfügbar.

Wie eine Reorganisation Mining-Nodes lahmlegen konnte

Die Schwachstelle mit hoher Schwere, CVE-2025-62861, betrifft die Versionen 28.0 bis 28.2 sowie 29.0 bis 29.1. Niklas Goegge meldete sie im September 2025. Der Fehler geht auf TRUC zurück — kurz für Topologically Restricted Until Confirmation —, auch bekannt als v3-Transaktionen. Diese Mempool-Richtlinie setzt strikte Grenzen dafür, wie unbestätigte Transaktionen voneinander abhängen dürfen. Ihr Hauptzweck ist es, Layer-2-Protokollen wie dem Lightning Network zu ermöglichen, Gebühren nachträglich zu erhöhen. Version 28.0 führte eine weitere Regel namens Sibling Eviction ein: Eine neue Transaktion darf versuchen, einem TRUC-Elternteil ein zweites Kind anzuhängen, und ersetzt bei ausreichend hohen Gebühren das bestehende Kind.

Der Fehler trat während einer Reorganisation auf, kurz „Reorg“ genannt — ein Ereignis, bei dem das Netzwerk die zuletzt hinzugefügten Blöcke durch eine andere Chain ersetzt. Bitcoin Core gibt zunächst die Transaktionen aus den abgetrennten Blöcken mit dem Flag bypass_limits=true in den Mempool zurück. Der Sibling-Eviction-Zweig respektierte dieses Flag jedoch nicht und lief dennoch. Infolgedessen verdrängte die Regel eine Transaktion, während ihre Nachfahren im Mempool verblieben, sodass sich im Mempool Transaktionen befanden, die Outputs ausgaben, die nicht mehr existierten. Wann immer der Node anschließend neue Blockvorlagen erstellen wollte, schlug die Gültigkeitsprüfung fehl.

Betroffene Miner konnten gültige Vorlagen erst wieder erzeugen, nachdem sie den Node neu gestartet hatten, da ein Neustart den Mempool in einem konsistenten Zustand neu lädt. Dennoch nennt das Advisory zu CVE-2025-62861 keinen anderen Workaround als das Update. Greg Sanders lieferte die Behebung in PR #33504, den das Projekt im Oktober 2025 in den Hauptzweig mergte und auf die Linien 28.x, 29.x und 30.x zurückportierte. Die Schwachstelle betraf nur die Vorlagenerstellung: Da TRUC eine Mempool-Regel und keine Konsensregel ist, berührte der Fehler nicht den Konsens. Mempool-Regeln wie TRUC sind lokale Richtlinien, die jeder Node auf seine eigenen ausstehenden Transaktionen anwendet, im Unterschied zu Konsensregeln, die jeder Node auf der gemeinsamen Chain durchsetzt.

Zwei Schwachstellen mittlerer Schwere 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 sitzt in der Verarbeitung von Compact Blocks, dem verkürzten Format, mit dem Nodes neue Blöcke aneinander weitergeben. Die betroffenen Versionen löschten den Download-Zustand eines solchen Blocks, bevor sie auf Witness-Malleation prüften — ein Begriff für eine nachträgliche Änderung der Witness-Daten. Schlug diese Prüfung fehl, forderte der Node die Daten erneut über GETDATA vom selben Peer an, mit einem Timeout von 10 Minuten — ungefähr dem durchschnittlichen Abstand zwischen Bitcoin-Blöcken. Ein bösartiger Peer, der zuerst einen Compact Block ankündigte, konnte die Blockverarbeitung des Opfers daher um bis zu 10 Minuten verzögern. Zudem konnte der Angreifer den Angriff unbegrenzt wiederholen, im -blocksonly-Modus oder wenn er alle drei High-Bandwidth-Peers kontrollierte — die kleine Gruppe von Peers, von denen ein Node priorisierte Block-Ankündigungen bezieht. PR #32646, im Juni 2025 gemergt, behob den Fehler.

Die zweite Schwachstelle mittlerer Schwere, CVE-2025-62860, betrifft Versionen vor 28.3, 29.2 und 30.0. Martin Zumsande und Antoine Poinsot meldeten sie im September 2025, zwei Wochen bevor Goegge die High-Schwachstelle meldete. In Bitcoin Core erscheinen eingehende Tor-Verbindungen unter der IP-Adresse des Tor-Daemons, des lokalen Dienstes, der den Datenverkehr aus dem Anonymisierungsnetzwerk weiterleitet. Lag diese Adresse in einem über -whitelist zugelassenen IP-Bereich, erhielten alle eingehenden Tor-Peers Whitelist-Berechtigungen. Diese Berechtigungen heben DoS-Limits und den Schutz vor Privacy-Leaks auf.

Laut dem Advisory hatten „tausende“ erreichbare Mainnet-Nodes diese Rechte allen eingehenden Tor-Verbindungen eingeräumt. Häufig hatten Anbieter, die Bitcoin Core gebündelt mit einem Tor-Daemon ausliefern, die Option gesetzt. Im Gegensatz dazu waren Nodes ohne diese optionale, nicht standardmäßige Einstellung nie betroffen. Seit PR #33395 berücksichtigt Bitcoin Core eingehende Tor-Peers bei der Zuweisung von Whitelist-Berechtigungen nicht mehr.

Das Projekt stuft beide Schwachstellen als Medium ein. Die Verzögerung der Blockverarbeitung war temporär, und Angreifer konnten sie nur in bestimmten Konstellationen beliebig oft wiederholen, während die Tor-Schwachstelle eine von der Standardeinstellung abweichende Konfiguration erforderte.

Warum ein Jahr zwischen Behebung und Veröffentlichung verging

Bitcoin Core trennt die Behebung bewusst von der Veröffentlichung. Die Korrektur wird zuerst in einem regulären Release ausgeliefert, und das Projekt beschreibt die Schwachstelle zu diesem Zeitpunkt nicht; Details folgen später, sobald die betroffenen Versionen älter sind oder ihr Support geendet hat. Dies gibt Betreibern Zeit zum Updaten.

Für die drei aktuellen Advisories gingen die Meldungen zwischen April und September 2025 ein, und die Behebungen flossen von Juni bis Oktober 2025 in den Code ein. Bitcoin Core 30.0, 29.2 und 28.3 erschienen dann mit den Korrekturen im Oktober 2025. Das Support-Ende bestimmte den Zeitpunkt der Veröffentlichung: Der Support für 29.x, die letzte anfällige Versionslinie, endete am 27. Oktober 2026, und die Advisories folgten am 10. November 2026 — 14 Tage später.

Der Advisory-Index des Projekts verwendet vier Schweregrade: Critical, High, Medium und Low. Alle drei Advisories liegen auf den mittleren Stufen. Der Zeitraum für CVE-2025-62859 fällt auf: Siegel meldete die Schwachstelle im April 2025, das Projekt mergte die Behebung im Juni 2025, und die Details wurden erst etwas mehr als 18 Monate nach der Meldung öffentlich.

Was die Schwachstellen für Miner und Node-Betreiber bedeuten

Die High-Schwachstelle betraf hauptsächlich Miner und Pools. Nur Nodes, die eine Reorg durchliefen und anschließend Blockvorlagen erstellen mussten, lösten den Fehler aus. Die beiden Medium-Schwachstellen trafen hingegen auch gewöhnliche Nodes, erforderten jedoch jeweils eine bestimmte Netzwerksituation oder Konfiguration.

Die Versionen 30.0 und 29.2 beheben alle drei Fehler, und 28.3 behebt zwei davon. Seit Ende Oktober 2026 erhält jedoch nur noch Software ab Version 30.x Support. Wer 29.x oder älter betreibt, nutzt daher nicht unterstützte Software — auch mit den Backports.

Die Advisories lassen mehrere Fragen offen. So ist etwa unklar, ob ein Angreifer die Reorg-Topologie, die den High-Fehler auslöst, gezielt erzeugen kann. Die Advisories sagen auch nicht, ob eine der drei Schwachstellen jemals ausgenutzt wurde, und es gibt keine genaue Zahl der vom Tor-Fehler betroffenen Nodes. Der Bericht zeigt jedoch, dass das Projekt alle drei Fehler etwas mehr als ein Jahr vor der Veröffentlichung behob und auslieferte.