Bitcoin Core legt drei per LLM gefundene Fehler offen
Victoria Shinder2 Min. LesezeitBitcoin Core veröffentlichte am 28. Oktober drei Sicherheitshinweise, einen Tag nach Auslieferung der Korrekturen, nach der in der Vorwoche eingeführten Regel für Fehler, die das Projekt als leicht auffindbar einstuft. Alle drei fand ein automatischer Scan mit einem großen Sprachmodell im Rahmen von Elias Rohrers Project Loupe; Mitwirkender Gregory Sanders prüfte sie, bevor sie an das Sicherheitsteam gingen.
Der schwerste, CVE-2026-117350, mittlere Stufe, betrifft Knoten unter Windows, macOS und BSD. Dort überwacht Bitcoin Core Sockets über ein select()-Backend statt über poll(), und dieser Pfad achtete auf Ausnahmezustände des Sockets auch dann, wenn das Lesen von einem Peer pausiert war. TCP-Urgent- oder Out-of-Band-Daten lösten trotzdem ein Lesen aus, sodass ein Peer die Warteschlangengrenze umgehen konnte. Laut Hinweis konnte ein bösartiger Peer jeden solchen verbundenen Knoten „trivial zum Absturz bringen“. Linux-Knoten sind nicht betroffen. Project Loupe meldete den Fehler am 23. Oktober; die Korrektur wurde am 26. Oktober übernommen und auf die Versionen 29 bis 32 zurückportiert.
Der zweite, CVE-2026-117349, ebenfalls mittel, betrifft Peers, die vorgeben, keine BIP-31-Pings mit Nonce zu unterstützen. Solche Peers werden bei unbeantworteten Pings nicht getrennt; ein bösartiger konnte daher das Lesen verzögern und seine Warteschlange von Transaktionsmeldungen um bis zu 2 MB pro Stunde je eingehender und 5 MB je ausgehender Verbindung wachsen lassen. Der Mitwirkende L0rinc fand denselben Fehler sechs Tage nach dem Scan unabhängig.
Der dritte, CVE-2026-117346, niedrige Stufe, erlaubt einem Miner, Undo-Dateien über 32-Bit-Offsets hinaus aufzublähen. Auf 64-Bit-Systemen nennt der Hinweis das unpraktikabel: Es bräuchte etwa einen Monat der gesamten Blockproduktion und eine genau platzierte Reorganisation. Unter Windows und auf 32-Bit-Systemen kann ein Knoten bei 2 GiB sofort stehen bleiben, ein Neustart hilft nicht. Die Korrekturen stecken in 29.5, 30.4, 31.2 und 32.1; 32-Bit-Systeme und Knoten mit Blockdaten auf FAT32 bleiben betroffen.
Was das bedeutet
Das Argument für die neue Regel steckt im zweiten Hinweis: Einen Fehler, den eine Maschine im September fand, fand ein Mensch binnen einer Woche erneut. Solche Lücken monatelang geheim zu halten, schützt wenig, wenn Scannen billig ist. Wer einen aus dem Internet erreichbaren Knoten außerhalb von Linux betreibt, sollte das Update als dringend behandeln; zudem kündigt das Projekt in zwei Wochen die Offenlegung von drei weiteren mittleren und schweren Fehlern an, die in 30.0 behoben wurden.