Bitcoin Core hat am 28. Oktober drei Sicherheitshinweise zu Bugs veröffentlicht, die ein automatisierter Scan mit einem Sprachmodell gefunden hat. Alle sind in den Versionen 29.5, 30.4, 31.2 und 32.1 behoben. Zwei Bugs erlauben es einem bösartigen Peer, den Speicher eines Nodes zu füllen, bis dieser sich beendet. Ein weiterer lässt sich nutzen, um jeden Node ohne Linux mühelos zum Absturz zu bringen.
Bug 1: TCP-Urgent-Daten unter Windows, macOS und BSD
Auf Plattformen außer Linux überwacht Bitcoin Core Sockets mit einem select()-basierten Backend. Dieses Backend prüfte auch dann auf Ausnahmezustände, wenn das Lesen von einem Peer pausiert war, wie aus dem Bitcoin-Core-Hinweis hervorgeht.
Ein Peer konnte TCP-Urgent-Daten (Out-of-Band) senden, den Backpressure-Mechanismus umgehen und unbegrenzt viele Daten in die Warteschlange legen. In der Praxis kann ein bösartiger Peer jeden Windows-, macOS- oder BSD-Node, mit dem er verbunden ist, mühelos zum Absturz bringen.
- Schweregrad: mittel, eingestuft als leicht auffindbar
- Linux-Nodes sind nicht betroffen, da sie poll() nutzen
- Am 23. Oktober identifiziert, PR #36665 von Antoine Poinsot am 26. Oktober eröffnet
Bug 2: langsames Speicherwachstum durch Pre-BIP31-Peers
Bitcoin Core legt Ankündigungen, vor allem Transaktions-INVs, für alle Peers in eine Warteschlange, auch für pausierte. Peers, die einen Nonce-Ping nicht innerhalb von 20 Minuten beantworten, werden getrennt. Diese Regel gilt aber nicht für Peers, die BIP 31 nicht unterstützen, heißt es im zweiten Hinweis.
Ein Angreifer kann vortäuschen, BIP 31 nicht zu unterstützen, und das Lesen von Nachrichten gezielt verzögern. So wächst die Warteschlange ohne Grenze.
- Speicherwachstum: bis zu 2 MB pro Stunde je eingehendem Peer und 5 MB pro Stunde je ausgehendem Peer
- Nodes mit -blocksonly sind deutlich weniger betroffen
- Mittlerer Schweregrad; von Loupe am 15. September gefunden und am 21. September unabhängig von L0rinc erneut entdeckt
Bug 3: Überlauf der Undo-Datei
Ein Miner kann gültige Blöcke erzeugen, deren Undo-Daten weit größer sind als die Blöcke selbst. Das reicht, um eine einzelne rev*.dat-Datei über 4 GiB zu treiben. Positionen wurden als 32-Bit-Ganzzahlen gespeichert, daher überschreiben neuere Undo-Daten ältere. Trifft eine spätere Reorg einen betroffenen Block, kann der Node ihn nicht lesen und beendet sich, erklärt der dritte Hinweis. Ein Neustart hilft nicht, zur Wiederherstellung braucht es einen -reindex mit einer korrigierten Version.
Unter Windows und auf 32-Bit-Systemen liegt die Grenze bei 2 GiB, und es ist keine Reorg nötig: Der Node kann Undo-Daten nicht schreiben und beendet sich bei jedem Neustart.
- Schweregrad: niedrig; die Ausnutzung auf 64-Bit-Systemen ist unpraktikabel
- Ein Angreifer müsste mehrere tausend Blöcke minen, etwa die Leistung des gesamten Netzwerks von einem Monat
- 32-Bit-Systeme und Nodes, die Blöcke auf FAT32 speichern, bleiben auch nach dem Fix betroffen
- Gemeldet von Loupe am 8. Juli, danach unabhängig von L0rinc (21. August) und Andrew Dorman (23. Oktober)
Wer die Bugs fand und warum sie schon öffentlich sind
Alle drei wurden durch einen automatisierten LLM-Scan im Rahmen von Project Loupe entdeckt, das Elias Rohrer bei Spiral leitet. Gregory Sanders validierte die Funde und gab sie an das Bitcoin-Core-Sicherheitsteam weiter.
Die Richtlinie von Bitcoin Core definiert leicht auffindbare Schwachstellen als solche, die sich mit minimalem Aufwand finden lassen, etwa mit einem einfachen LLM-Prompt. Dafür veröffentlicht das Team für jede gepflegte Hauptversion ein Point Release mit dem Fix sowie einen Hinweis, ohne die übliche Embargofrist.
Nach dem normalen Zeitplan werden Bugs mit mittlerem und hohem Schweregrad zwei Wochen nach dem Support-Ende der letzten betroffenen Version offengelegt, etwa ein Jahr nach der ersten Hauptversion mit dem Fix.
Behobene Versionen | Veröffentlichungsdatum |
|---|---|
31.2 und 32.1 | 27. Oktober 2026 |
29.5 und 30.4 | 28. Oktober 2026 |