Bitcoin Core legt Schwachstelle bei Tor-Vertrauen und Bug bei Mining-Nodes offen – im Oktober gepatcht
Bitcoin Core veröffentlichte am 10. November Sicherheitshinweise zu drei Schwachstellen, darunter CVE-2025-62860, durch die eingehende Tor-Verbindungen auf einigen Nodes Trusted-Peer-Berechtigungen erhielten. Die Fehler wurden in den Oktober-Releases behoben, betroffene Betreiber werden aufgefordert, ihre Software zu aktualisieren.
Verfasst von der KI-Redaktion von CoinArticle · auf Basis von 2 angegebenen Quellen. So arbeiten wir
Was die Hinweise offenlegen
Bitcoin Core veröffentlichte seine Sicherheitsmitteilung am 10. November und nannte drei Schwachstellen, die alle in im Oktober ausgelieferten Releases behoben wurden. Am auffälligsten ist CVE-2025-62860, durch die eingehende Tor-Verbindungen auf Tausenden erreichbaren Mainnet-Nodes Trusted-Peer-Berechtigungen erhalten konnten. Eine zweite Schwachstelle, CVE-2025-62861, mit hohem Schweregrad eingestuft, konnte dazu führen, dass ein Mining-Node keine Blöcke mehr produziert, bis er neu gestartet wird. Eine dritte, CVE-2025-62859, mit mittlerem Schweregrad eingestuft, betrifft das Relay kompakter Blöcke. Die Mitteilung wurde veröffentlicht, nachdem die 29.x-Release-Reihe am 27. Oktober das Ende des Supports erreicht hatte.
Die Tor-Whitelist-Schwachstelle
Laut Hinweis erschienen eingehende Tor-Peers gegenüber Bitcoin Core unter der IP-Adresse der lokalen Tor-Software, die typischerweise auf demselben Rechner oder im selben Netzwerk läuft. Lag diese Adresse innerhalb eines Bereichs, der über die optionale Option -whitelist festgelegt wurde, erbten äußere Verbindungen Berechtigungen, die für vertrauenswürdige Peers vorgesehen sind. Diese Berechtigungen heben bestimmte Denial-of-Service-Limits und Schutzmechanismen gegen das Abfließen privater Informationen auf. Beliebte Anbieter lieferten Bitcoin Core zusammen mit Tor aus und konfigurierten passende Whitelist-Bereiche, weshalb die Angreifbarkeit Tausende Nodes erreichte. Nodes, bei denen die nicht standardmäßige Einstellung nie aktiviert wurde, waren nicht betroffen.
Der Fehler wurde dem Sicherheitsteam am 12. September 2025 von Martin Zumsande und Antoine Poinsot gemeldet, die Korrektur, die eingehende Onion-Verbindungen von den Whitelist-Berechtigungen ausschließt, wurde am 17. September zusammengeführt. Software-Anbieter wurden zwei Tage später informiert. Bitcoin Core 30.0 lieferte die Korrektur am 10. Oktober aus, gefolgt von 29.2 am 14. Oktober, und der Hinweis führt 28.3 sowie spätere Minor-Releases als gepatcht auf.
Der Bug bei Mining-Nodes bei Reorganisationen
CVE-2025-62861 betraf die Versionen 28.0 bis 28.2 sowie 29.0 bis 29.1. Er entsteht bei Kettenreorganisationen, wenn Transaktionen aus getrennten Blöcken in den Mempool zurückkehren, also den Pool unbestätigter Transaktionen des Nodes. Transaktionen der Version 3, bekannt als TRUC-Transaktionen, beschränken normalerweise die Beziehungen zwischen unbestätigten Transaktionen, und zurückkehrende Transaktionen sollen diese Limits bei einer Reorg umgehen. Eine Regel zum Ersetzen von Transaktionen blieb in diesem Prozess aktiv, wodurch eine wiederhergestellte Transaktion entfernt werden konnte, während abhängige Transaktionen zurückblieben. Der daraus resultierende inkonsistente Mempool führte dazu, dass Blockvorlagen die Validierung nicht bestanden, und die Blockproduktion konnte erst wieder aufgenommen werden, wenn ein Neustart den Mempool neu lud. Niklas Goegge meldete das Problem am 26. September 2025, die Korrektur wurde am 2. Oktober zusammengeführt. Entwickler Greg Sanders erläuterte in der Dokumentation zur Korrektur, dass das Überspringen der TRUC-Prüfungen bei Reorgs das beabsichtigte Verhalten gewesen sei, das entsprechende Umgehungsargument jedoch nicht geprüft worden war.
Blockierung durch kompakte Blöcke
CVE-2025-62859 ist ein Problem mit mittlerem Schweregrad bei kompakten Blöcken, einer bandbreitensparenden Methode zur Weitergabe von Blöcken zwischen Nodes. Ein böswilliger Peer, der zuerst einen kompakten Block ankündigt, kann ein Opfer dazu bringen, den vollständigen Block von genau diesem Peer anzufordern und nach einer fehlgeschlagenen Prüfung veränderter Transaktions-Witness-Daten einen Timeout von 10 Minuten abzuwarten. Laut Mitteilung könnte ein Angreifer, der alle drei Hochbandbreiten-Peers eines Opfers kontrolliert, die Blockierung auf unbestimmte Zeit wiederholen. Nodes, die mit -blocksonly laufen, waren ebenfalls anfällig für wiederholtes Blockieren. Eugene Siegel meldete die Schwachstelle am 28. April 2025.
Zeitpunkt der Offenlegung
Die Offenlegungsrichtlinie von Bitcoin Core hält Details zu Schwachstellen mit mittlerem und hohem Schweregrad in der Regel bis zwei Wochen nach dem Ende des Lebenszyklus des letzten betroffenen Releases zurück. Die veröffentlichte Zeitleiste zeigt, dass die Tor-Korrektur etwa sieben Wochen vor der öffentlichen Offenlegung zusammengeführt wurde, die Korrektur für Mining-Nodes etwa fünf Wochen vorher. Die Berichterstattung unterscheidet sich darin, wie der Zeitpunkt zu bewerten ist: CoinDesk beschreibt die Tor-Schwachstelle als bis Dienstag unter Verschluss gehalten, während Crypto.news die Offenlegung so darstellt, dass die Entwickler die Details zusammen mit den beiden anderen Schwachstellen nach dem Ende-des-Supports-Datum der 29.x-Reihe veröffentlichten. Beide Darstellungen stimmen bei den Patch-Daten und dem Auslöser des Supportendes überein, die Hinweise selbst bezeichnen die Offenlegung jedoch nicht als über die Richtlinie hinaus verzögert.
Die Hauptzielgruppe des Hinweises sind Betreiber, auf denen betroffene Versionen oder Whitelist-Konfigurationen laufen, und die gepatchten Releases sind der dokumentierte Weg zur Behebung.
Warum es wichtig ist
Für Trader
Die Fehler sind behoben, und das Mining-Problem betraf nur bestimmte Versionsbereiche, weshalb der kurzfristige Kursdruck wahrscheinlich begrenzt bleibt, auch wenn Miner auf betroffenen Releases überprüft werden sollten.
Für Investoren
Offenlegungen dieser Art verdeutlichen den Sicherheitsprüfungsprozess, den Bitcoin Core auf seine Codebasis anwendet, ein Faktor, der für das langfristige Vertrauen in Node-Software relevant ist.
Für Entwickler
Wer Dienste betreibt, die sich auf -whitelist oder das Vertrauen zu Tor-Peers stützen, sollte die Konfiguration prüfen und sicherstellen, dass 30.0, 29.2 oder Releases der Reihe 28.3 oder neuer laufen.
Dieser Artikel dient nur zur Information und stellt keine Finanzberatung dar. Vollständigen Haftungsausschluss lesen.
