Die Referenzimplementierung von Bitcoin. Ihre Website veröffentlicht Ankündigungen neuer Versionen, Sicherheitshinweise und Stellungnahmen des Projekts.
Ein Miner konnte eine Undo-Datei von Bitcoin Core über 4 GiB hinaus aufblähen. Ihre 32-Bit-Positionen laufen dann über, Daten werden beschädigt, und folgt ein passender Reorg, fahren Knoten herunter; unter Windows und auf 32-Bit-Systemen ist schon bei 2 GiB Schluss, ganz ohne Reorg. CVE-2026-117346 ist als niedrig eingestuft, der Angriff bräuchte rund einen Monat lang sämtliche Blöcke des Netzes. Auf 64-Bit-Systemen beheben 32.1, 31.2, 30.4 und 29.5 das Problem, 32-Bit-Knoten und Blockspeicher auf FAT32 bleiben betroffen.
poll() und select() überwachen Socket-Exceptions in Bitcoin Core 29.5 jetzt auf dieselbe Weise (#36665), für pausierte Send-Peers greift ein verbindliches Timeout (#36667). Flatfile-Positionen wechseln auf 64-Bit-Ganzzahlen (#36669), bei Adressen aus Seeds gehen Knoten von v2transport aus, und ein DNS-Seed fällt weg.
Gab ein bösartiger Peer vor, BIP-31-Pings nicht zu beherrschen, entging er der Trennung nach 20 Minuten und konnte langsam lesen. Die Sendewarteschlange eines Knotens wuchs dadurch um bis zu 2 MB pro Stunde je eingehendem und 5 MB je ausgehendem Peer. Bitcoin Core 32.1, 31.2, 30.4 und 29.5 schließen die als mittelschwer eingestufte Lücke CVE-2026-117349 mit #36667; -blocksonly-Knoten waren deutlich weniger gefährdet.
Knoten unter Windows, macOS und BSD ließen sich von einem verbundenen Peer mit TCP-Urgent-Daten zum Absturz bringen: Die Daten umgingen im select()-Backend pausierte Lesevorgänge, der Speicher lief ohne Obergrenze voll (CVE-2026-117350). Linux-Knoten arbeiten mit poll() und bleiben verschont. Die als mittelschwer eingestufte Lücke, aufgespürt von einem LLM-Scan im Rahmen von Project Loupe, beheben Bitcoin Core 32.1, 31.2, 30.4 und 29.5.
Bitcoin Core 30.4 wertet die Bits 5 bis 28 aus BIP 9 gemäß BIP 323 nicht mehr als Soft-Fork-Signale, Blöcke mit diesen Bits lösen also keine Warnungen vor unbekannten Deployments mehr aus (#34779). Im Netzwerkteil gilt nun ein Timeout für pausierte Send-Peers (#36667), Flatfile-Positionen nutzen jetzt 64-Bit-Ganzzahlen (#36669).
Für Private Broadcast zieht Bitcoin Core 31.2 eine Obergrenze ein: Die Warteschlange der noch nicht vom Netz zurückgemeldeten Transaktionen endet bei 10.000 Einträgen. Ist sie voll, lehnt sie neue Einreichungen ab, und Aufrufer müssen sie mit abortprivatebroadcast leeren (#35406). Die Versionsbits 5 bis 28 gelten laut BIP 323 nicht länger als Soft-Fork-Signale.
Private Broadcast gefährdet in Bitcoin Core 32.1 nicht mehr die IP-Adresse des Absenders: Das Leck konnte entstehen, wenn eine gescheiterte v2-Verbindung den Neuversuch per v1 direkt statt über Tor startete. Der Standardwert von -maxconnections steigt von 125 auf 200, das Tempo ausgehender Transaktionen regelt nun ein globaler Backlog statt einer Grenze je Peer.
Hinter starker Lese- und Schreiblast im Normalbetrieb steckt ein Fehler, den Bitcoin Core 29.4 behebt: Die Chainstate-Datenbank schrieb große Teile von sich selbst immer wieder neu. Der Fix schaltet die Seek Compaction von LevelDB ab und verdichtet den Chainstate stattdessen regelmäßig (#35465).
Mit dem ständigen Umschreiben des Chainstate ist in Bitcoin Core 30.3 Schluss. Repariert sind auch ein Absturz im Feebumper, wenn die kombinierte Bump-Gebühr nicht verfügbar ist (#34870), und ein Fehler in der Coin Selection, der einen Betrag als Boolean berechnete (#34888). Bei PSBT werden MuSig2-Pubkeys nun beim Deserialisieren von Pubnonce und Teilsignatur geprüft (#34219).
Ein IP-Leck in -privatebroadcast schließt Bitcoin Core 31.1: Manche Verbindungen liefen über das Clearnet statt über das aktivierte Privacy-Netz. Außerdem enden die Chainstate-Neuschreibungen, die für übermäßige Plattenaktivität sorgten, und die MuSig2-Schlüsselaggregation weist eine leere Pubkey-Liste ab (#35316).
Scheitert der v2-Handshake, kann Bitcoin Core 31.0 die IP-Adresse des Absenders preisgeben: Mit gesetztem -privatebroadcast läuft der Neuversuch per v1 am Tor-Proxy vorbei direkt zum Peer. Wahrscheinlicher Auslöser ist ein bösartiger Peer, der den Handshake absichtlich abbricht. Bis 31.1 erscheint, können Nutzer die Funktion abschalten, -v2transport=0 setzen oder ausgehendes IPv4/IPv6 über Tor leiten.
Bitcoin-Core-Versionen nach 0.14.0 und vor 29.0 konnten beim Prüfen eines präparierten ungültigen Blocks bereits freigegebenen Speicher lesen, der Knoten stürzte dann ab. CVE-2024-52911 ist als hoch eingestuft, allerdings muss ein Angreifer gültigen Proof-of-Work an der Chain-Spitze aufwenden; Remote Code Execution gilt als unwahrscheinlich. Gemeldet hat die Lücke Cory Fields, der Fix steckt in 29.0.
Cluster Mempool löst in Bitcoin Core 31.0 das alte Design ab: Statt Ancestor- und Descendant-Limits gibt es Cluster mit höchstens 64 Transaktionen und 101 kB, der CPFP-Carveout entfällt. Der Standardwert von -dbcache steigt auf Rechnern mit mindestens 4096 MiB RAM auf 1024 MiB. Neu ist die Option -privatebroadcast, die sendrawtransaction-Broadcasts nur noch über Tor oder I2P verschickt.
Zwei Fehler rund um unbenannte Wallets behebt Bitcoin Core 28.4: bei der Migration von Legacy-Wallets (#34156) und in createfromdump, das im Fehlerfall das Wallets-Verzeichnis löschte (#34215). Zudem fliegt ein DNS-Seed aus den chainparams (#33723).
Peers, die konsensungültige Transaktionen schicken, bestraft Bitcoin Core 29.3 nicht mehr (#33050). Die Validierung erhält einen Sighash-Midstate-Cache pro Input für Legacy-, P2SH- und SegWit-v0-Skripte (#32473) und erkennt Witness Stripping, ohne Script-Prüfungen erneut auszuführen (#33105). Aus addPackageTxs im Miner verschwindet ein Unsigned-Integer-Überlauf (#33475).
Der Migrationsfehler bei unbenannten Legacy-Wallets ist mit Bitcoin Core 30.2 Geschichte (#34156), und createfromdump löscht beim Scheitern an einer solchen Wallet nicht mehr das Wallets-Verzeichnis (#34215). Auch hängt Strg-C bei IPC-Wait-Aufrufen nicht mehr (#33511).
In seltenen Fällen kann eine misslungene wallet.dat-Migration in Bitcoin Core 30.0 oder 30.1 alle Dateien im Wallet-Verzeichnis löschen, Guthaben sind damit in Gefahr. Die Entwickler haben die Binaries zurückgezogen und bitten, bis 30.2 weder über die GUI noch per RPC zu migrieren. Betroffen ist nur, wer eine unbenannte wallet.dat (Standard) hat, die sich nicht migrieren oder laden lässt.
Unbestätigte TRUC-Coins mit Ancestors berücksichtigen Wallets in Bitcoin Core 30.1 nicht mehr (#33528). Bei IPC entfällt für Optionen die Pflicht zum Argument -m (#33229), das Logging von Nachrichten kostet weniger Overhead (#33517), und laufende waitNext-Aufrufe lassen sich abbrechen (#33676).
Präparierte, nicht standardkonforme Transaktionen konnten einen Bitcoin-Core-Knoten jeweils einige Sekunden beschäftigen, ohne dass der Absender getrennt wurde; so ließ sich die Verbreitung von Blöcken verzögern. Die als niedrig eingestufte Lücke CVE-2025-46598 meldete Antoine Poinsot, v30.0 entschärft sie durch eine kürzere Validierungszeit im schlimmsten Fall.
Blöcke über 1 GB konnten auf 32-Bit-Knoten von Bitcoin Core eine Größenprüfung überlaufen lassen und beim Schreiben auf die Platte einen Absturz auslösen. Das klappt allerdings nur als Compact Block und nur bei einem Opfer, das -maxmempool über 3 GB betreibt und 1 GB Transaktionen im Mempool hält. Entdeckt hat CVE-2025-46597 Pieter Wuille, die Einstufung lautet niedrig; eine Obergrenze für -maxmempool auf 32-Bit-Systemen schloss die Lücke in 29.1 und 30.0.
