Aktualisiert am 31. Oktober 2026.
Bitcoin Core veröffentlichte am 28. Oktober drei Sicherheitshinweise zu Schwachstellen, die den Betrieb von Nodes beeinträchtigen können. Die Versionen 29.5, 30.4, 31.2 und 32.1 enthalten Korrekturen, allerdings unterscheiden sich die betroffenen Plattformen. Beim Undo-Dateiproblem bleiben Einschränkungen für 32-Bit-Systeme und FAT32 bestehen.
Der unmittelbarste Fall betrifft Windows, macOS und BSD: Ein verbundener bösartiger Peer kann über dringliche TCP-Daten den Arbeitsspeicher erschöpfen. Linux ist von diesem konkreten Fehler nicht betroffen. Das nimmt Linux jedoch nicht von den anderen Hinweisen aus und macht hohen RAM-Verbrauch allein noch nicht zum Beleg eines Angriffs.
Bitcoin Core: Welche Versionen die Korrekturen enthalten
Alle drei Hinweise nennen dieselben vier korrigierten Versionen. Die Veröffentlichung von Bitcoin Core 32.1 ist auf der offiziellen Website angekündigt. Zur Auswahl eines Updates gehören außerdem die jeweiligen Versionshinweise und die Prüfung, ob es zur tatsächlich betriebenen Installation passt.
Die Liste ist keine Empfehlung, dauerhaft auf einem älteren Entwicklungszweig zu bleiben. Sie zeigt, wo diese Korrekturen ausgeliefert wurden, garantiert aber keine zukünftige Wartung sämtlicher Zweige. Dieser Artikel gibt den Informationsstand vom 31. Oktober wieder; spätere Veröffentlichungen müssen anhand der Projektdokumentation beurteilt werden.
| Hinweis | Problem | Wichtige Abgrenzung |
|---|---|---|
| CVE-2026-117350 | Unbegrenzter Speicherverbrauch durch dringliche TCP-Daten | Nicht-Linux-Codepfad; mittlerer Schweregrad |
| CVE-2026-117349 | Langsames Wachstum einer Ankündigungswarteschlange bei Prä-BIP31-Peers | Eigenständig gegenüber dem TCP-Fehler; mittlerer Schweregrad |
| CVE-2026-117346 | Überlauf von Undo-Dateien | Extreme Voraussetzungen; niedriger Schweregrad, verbleibende 32-Bit-/FAT32-Grenzen |
Der TCP-Fehler betrifft Linux nicht
Der TCP-Sicherheitshinweis beschreibt einen Fehler im auf select() beruhenden Überwachungspfad für Netzwerkverbindungen, nicht im Linux-Pfad. Ein außergewöhnlicher Socket-Zustand konnte weitere Lesevorgänge auslösen, obwohl normale Lesevorgänge zum Schutz der Verarbeitungswarteschlange bereits angehalten waren.
Dadurch konnte die Speichernutzung bis zum Absturz des Nodes wachsen. Das Projekt stuft die Schwachstelle als mittelschwer ein und beschreibt einen verbundenen Peer, keinen Zugriff auf private Schlüssel. Maßgeblich ist das Betriebssystem des Nodes, nicht das eines Telefons, mit dem sein Besitzer einen Kontostand betrachtet.
Eine zweite Lücke vergrößert die Sendewarteschlange langsam
Der Hinweis zu Prä-BIP31-Peers betrifft Ankündigungen für eine Gegenstelle, die zu langsam liest. Ein Peer konnte fehlende Unterstützung für BIP31-Pings mit Nonce behaupten und so die übliche Trennung bei ausbleibender Antwort umgehen. Bestimmte Nachrichten wurden dennoch weiter eingereiht.
Das Projekt nennt ein Wachstum von bis zu 2 MB pro Stunde je eingehendem und 5 MB je ausgehendem Peer. Diese Werte beschreiben das konkrete Szenario, nicht den erwarteten Verbrauch jeder Installation. Nodes mit -blocksonly sind deutlich weniger betroffen, weil Transaktionsankündigungen den Großteil der Warteschlange ausmachen; daraus folgt aber kein Ersatz für ein Update.
Undo-Dateien: Warum 32 Bit und FAT32 relevant bleiben
Undo-Daten werden benötigt, um bei einer Reorganisation Blöcke von der Kette zu lösen. Der Überlaufhinweis beschreibt extreme Bedingungen, unter denen ungewöhnlich große Datenmengen benötigte Informationen beschädigen und den Node anhalten können. Das Projekt bewertet den Schweregrad als niedrig und hält die Ausnutzung auf 64-Bit-Systemen unter den beschriebenen Voraussetzungen für unpraktikabel.
Die Korrektur verwendet 64-Bit-Positionen, lässt aber ausdrücklich Einschränkungen für 32-Bit-Systeme und Blockverzeichnisse auf FAT32 bestehen. Eine korrigierte Versionsnummer macht die Prüfung von Architektur und Dateisystem deshalb nicht überflüssig. Auch Windows-Aufrufe zur Dateipositionierung wurden korrigiert; das ist von der weiterhin bestehenden allgemeinen 32-Bit-Einschränkung zu unterscheiden.
Ein Node-Absturz belegt keinen Diebstahl aus der Wallet
Die Veröffentlichungen melden kein automatisches Auslesen von Seed-Phrasen oder privaten Schlüsseln. Node-Betrieb und Schlüsselverwahrung sind unterschiedliche Aufgaben, wie unsere Erklärung zu Custodial- und Non-Custodial-Wallets erläutert. Ein Ausfall ist trotzdem relevant, beweist für sich genommen jedoch keinen Diebstahl des Guthabens.
Andere Meldungen haben außerdem andere Ursachen. max-fee-exceeded betrifft beispielsweise eine Gebührenschutzfunktion und nicht diese Schwachstellen. Wer unterschiedliche Symptome gleichsetzt, riskiert unnötige oder falsche Eingriffe. Zunächst müssen die laufende Version, die Plattform und der tatsächlich beobachtete Fehler feststehen.
Vor einer Wiederherstellung zuerst den Zustand prüfen
Die Hinweise führen die Entdeckungen auf einen Sprachmodell-Scan im Project Loupe zurück und nennen eine menschliche Validierung vor der Weitergabe an das Sicherheitsteam. Ein automatisch erzeugter Verdacht, eine bestätigte Schwachstelle und eine ausgelieferte Korrektur sind unterschiedliche Schritte. Daraus ergibt sich kein Beleg, dass ein Modell beliebige Software selbstständig und zuverlässig reparieren könnte.
Für zwei der Probleme sind außerdem unabhängige Wiederentdeckungen dokumentiert. Der Einsatz von KI verändert die praktische Aufgabe des Betreibers nicht: Er muss feststellen, welcher Code tatsächlich läuft und welche beschriebenen Bedingungen auf seine Maschine zutreffen. Eine Schlagzeile über automatische Entdeckung ersetzt weder diese Bestandsaufnahme noch die Kontrolle nach einem Update.
Für Betreiber sind die tatsächlich laufende Version, das Betriebssystem, die Architektur und das Dateisystem des Blockverzeichnisses die ersten Prüfpunkte. Updates sollten aus offiziellen Quellen stammen, nach den Echtheitsprüfungen des Projekts und unter Erhalt der Wallet-Sicherungen. Ein legitimes Update verlangt niemals die Weitergabe einer Seed-Phrase an einen vermeintlichen Supportdienst.
Zusätzlich ist zwischen erfolgreicher Installation und tatsächlicher Ausführung zu unterscheiden. Ein heruntergeladenes Paket oder eine ersetzte Datei beweist noch nicht, dass der Prozess bereits mit der neuen Version arbeitet. Diese Kontrolle ist eine betriebliche Vorsichtsmaßnahme, keine Aussage darüber, dass eine bestimmte Installation schon angegriffen wurde oder dass jeder hohe Speicherverbrauch dieselbe Ursache hat.
Der Undo-Hinweis nennt eine Neuindizierung mit korrigierter Version als Wiederherstellung für den beschriebenen Schaden. Das ist keine Aufforderung, bei jedem langsamen Node -reindex auszuführen: Diagnose, Datensicherung und verfügbare Ressourcen gehen vor. Wir haben weder Angriffe nachgestellt noch eine Installation getestet, sondern die veröffentlichten Korrekturen und ihre ausdrücklich genannten Grenzen verglichen.
