Bitcoin Core hat die offizielle Offenlegung von CVE-2025-62861 veröffentlicht – eine Schwachstelle hoher Schwere in der Transaction-Relay-Logik der Node-Software, die Mining-Betriebe ohne sichtbare Warnung auf veralteten Blocktemplates weiterrechnen lassen konnte. Der Advisory schreibt die Meldung des Sicherheitsforschers Niklas Goegge zu und führt die Schwachstelle auf eine Relay-Regel zurück, die im falschen Moment auslöste: während einer Chain-Reorganization, obwohl sie still bleiben sollte.

Betroffen sind die Versionen von Bitcoin Core 28.0 bis 28.2 sowie 29.0 bis 29.1. Der Fix erschien im Oktober 2025, die vollständigen technischen Details wurden jedoch gemäß der koordinierten Disclosure-Richtlinie des Projekts bis November 2026 zurückgehalten. Der Advisory nennt keinen Ausfall und keinen betroffenen Betreiber; die Exposition liegt in der Vergangenheit. Mining-Hardware, die auf eine Node in diesem korrumpierten Zustand zeigte, hätte weitergerechnet – aber auf dem zuletzt empfangenen Template, sodass neue Transaktionen und ihre Gebühren ungenutzt blieben, bis jemand es bemerkte.

Wie eine Reorganization eine Transaktion verwaisen kann

Eine Reorganization findet statt, wenn eine Node ihre aktuelle Chain-Spitze zugunsten eines konkurrierenden, schwereren Zweigs aufgibt. Die Transaktionen aus den gerade getrennten Blöcken bleiben gültig, sodass Bitcoin Core sie zurück in den Mempool legt, den Ablagebereich für unbestätigte Transaktionen. Da diese Transaktionen bereits in einem gültigen Block bestätigt waren, fügt die Node sie mit einem Flag namens bypass_limits erneut hinzu, das die üblichen Anti-Spam- und Topologie-Prüfungen abschaltet. Ziel ist es, den Pool originalgetreu wiederherzustellen – nicht, Transaktionen, die den Konsens bereits passiert haben, neu zu bewerten.

Eine der Prüfungen, die hätten abgeschaltet werden sollen, betrifft Transaktionen der Version drei, sogenannte TRUC-Transaktionen. Gemäß BIP 431 darf eine TRUC-Transaktion höchstens einen unbestätigten Elternteil und ein unbestätigtes Kind haben. Das ist eine Relay-Richtlinie, keine Konsensregel: Ein Block darf legitim einen TRUC-Elternteil mit mehreren Kindern enthalten, obwohl keine Node diese Struktur aus dem Netzwerk in ihren Mempool aufnehmen würde. Dieselbe Grenze zwischen Richtlinie und Konsens bestimmte auch die Grenze der Schwachstelle selbst: CVE-2025-62861 konnte den Mempool einer Node korrumpieren und ihre Template-Ausgabe blockieren, aber keinen ungültigen Block erzeugen oder die Regeln der Chain ändern.

Seit Version 28.0 setzt Bitcoin Core die Ein-Kind-Grenze über einen Mechanismus namens Sibling Eviction durch. Wenn eine neue Transaktion einem TRUC-Elternteil ein zweites unbestätigtes Kind verschaffen würde, behandelt die Node das vorhandene Kind als Ersetzungskandidaten und verdrängt es – sofern die neue Transaktion ausreichend Gebühren zahlt – nach den Replace-by-Fee-Regeln.

Der Fehler bestand darin, dass die Sibling Eviction selbst dann lief, wenn bypass_limits gesetzt war. Eine Reorganization, die einen TRUC-Elternteil mit mehreren Kindern wiederherstellte – eine im getrennten Block völlig gültige Struktur – konnte die Verdrängung einer wiederhergestellten Transaktion auslösen, während die Transaktionen, die ihre Outputs ausgaben, im Pool verblieben. Der Mempool enthielt nun Kinder, deren Elternteil nirgendwo mehr existierte: nicht in der Chain und nicht im Pool.

Der Fix von Greg Sanders koppelte die TRUC-Prüfungen an bypass_limits, sodass die Verdrängung während der Wiederherstellung nach einer Reorganization nicht mehr läuft. Der zugehörige Pull Request, PR #33504, ergänzte zudem das Testszenario, das im ursprünglichen Code fehlte: Transaktionen, die aus getrennten Blöcken statt von Peers eintreffen.

Wie ein stillgelegtes Template aus Mining-Sicht aussieht

Eine Node übergibt Arbeit über getblocktemplate an die Mining-Software, das einen Kandidatenblock zusammenstellt, ihn durch die eigene Gültigkeitsprüfung der Node führt und den vorherigen Blockhash, die ausgewählten Transaktionen und die nächste Höhe zurückgibt. Mit einer elternlosen Transaktion im Pool scheiterte der zusammengestellte Kandidat an dieser Prüfung, sodass der Aufruf keine frische Arbeit liefern konnte.

Von außen erschien die Node gesund:

• Prozess läuft
• Peer-Verbindungen offen
• Chain-Spitze schreitet voran
• Mempool nimmt neue Transaktionen an

Tatsächlich defekt war:

• Die Template-Anfrage gibt einen Fehler zurück
• Hasher arbeiten weiter auf veralteter Arbeit
• Auf der aktuellen Spitze kann kein Block gefunden werden
• Der Zustand besteht fort, bis die Node neu gestartet wird

Alles, was ein generisches Monitoring-Dashboard überwacht, wäre grün geblieben. Auch das Netzwerk gab kein Signal zurück: Die Chain-Spitze schritt weiter voran – Blöcke wurden weiterhin gefunden, nur eben nicht von diesem Betrieb –, sodass die Kosten beim stillgelegten Miner allein lagen: in Rechenleistung, die auf der aktuellen Spitze keinen Block erzeugen konnte, und in Gebühren, die er sonst erhalten hätte. Das Eine, das ein Miner von der Node benötigt – ein aktuelles Template –, war das Eine, das sie nicht mehr lieferte.

Neustart, Patch und Ende der Unterstützung

Ein Neustart der Node lädt den Mempool in einem konsistenten Zustand von der Festplatte neu, was das Symptom beseitigt. An der Ursache ändert das nichts: Die nächste Reorganization mit derselben Transaktionsstruktur könnte die Node erneut stilllegen.

Die zugrunde liegende Schwachstelle wurde in drei Releases beseitigt. Version 30.0 erschien mit dem Fix am 10. Oktober 2025, Backports folgten in 29.2 und 28.3. Vom privaten Bericht bis zum letzten dieser Releases vergingen drei Wochen:

Beide Backport-Zweige haben seither die Unterstützung verloren. Die Wartungsrichtlinie von Bitcoin Core umfasst die drei neuesten Hauptversionen – derzeit 30.x, 31.x und 32.x –, und 29.x erreichte am 27. Oktober 2026 ihr End-of-Life. Ein Betreiber, der auf den ursprünglichen Fehler nur mit einem Neustart reagierte, läuft nun mit nicht mehr unterstütztem Code – bei einer öffentlich beschriebenen Auslösung, die genau angibt, welche Transaktionsstruktur den Fehler auslöst.

Warum der Advisory 396 Tage wartete

Vom ersten gefixten Release bis zum ausführlichen Advisory vergingen 396 Tage, und die Offenlegung erschien genau zwei Wochen nach dem End-of-Life von 29.x. Keine der beiden Zahlen ist Zufall. Die Disclosure-Richtlinie von Bitcoin Core hält Details mittlerer und hoher Schwere zurück, bis zwei Wochen nach dem Verlust der Unterstützung des letzten betroffenen Releases vergangen sind, mit einer Vorankündigung zwei Wochen zuvor, abgestimmt auf ein neues Hauptrelease.

Die Embargofrist betraf die Erklärung, nicht den Code. Der Pull Request ist seit dem 29. September 2025 öffentlich, und die Release Notes von 28.3 und 29.2 führten seinerzeit einen Mempool-Fix auf. Ein Jahr lang privat blieb der Bericht, der den Patch mit einem reproduzierbaren Mining-Stillstand verbindet.

Die Richtlinie bietet allerdings auch einen schnelleren Weg. Als leicht auffindbar eingestufte Fehler – das Projekt definiert sie als mit minimalem Aufwand auffindbar – erhalten ein sofortiges Point-Release und einen Advisory ohne Embargo. Dieser Fall durchlief den Standardzeitplan, die Maintainer hielten ihn also nicht für trivial auffindbar. Er wurde am selben Tag zusammen mit zwei weiteren Advisories hoher und mittlerer Schwere veröffentlicht, die einen Blockverarbeitungs-Stillstand und einen Tor-Berechtigungsfehler betrafen; alle drei wurden im selben Release-Zyklus im Oktober 2025 behoben. Ein Build, der neu genug ist, um den Mempool-Patch zu tragen, trägt damit auch die beiden anderen Fixes.

Der langsamere Weg verkörpert seine eigene Annahme: dass Betreiber innerhalb des einjährigen Fensters upgraden, sodass bis zur öffentlichen Beschreibung der Auslösung niemand Verwundbarer noch zuhört.

Was statt Uptime überwacht werden sollte

Für einen Mining-Betrieb ist die nützliche Prüfung nicht, ob die Node lebt, sondern wie alt ihr zuletzt erfolgreiches Template ist. Ein Prozess, der läuft, verbunden und synchronisiert ist, kann dennoch aufgehört haben, Arbeit zu liefern – und diese Schwachstelle war eine Möglichkeit dafür, lautlos zu geschehen. Die Build-Version gehört in dieselbe Prüfung, denn eine Node, die heute aktuelle Templates liefert, kann morgen ohne Unterstützung sein.

Für Backup-Template-Quellen gilt dieselbe Frage. Eine Failover-Node mit demselben Release und derselben Mempool-Richtlinie hätte dieselbe Reorganization und denselben Stillstand erlebt; zwei laufende Prozesse sind keine zwei unabhängigen Arbeitsquellen. Nur eine Node auf einem anderen, gepatchten Build hätte den Betrieb am Minieren gehalten – und nur ein Betreiber, der das unter einer simulierten Reorganization getestet hätte, hätte dies im Voraus gewusst.