Drie kwetsbaarheden in Bitcoin Core: dit kun je nu doen

Bitcoin Core heeft op 28 oktober 2026 drie veiligheidsmeldingen tegelijk gepubliceerd. De ernstigste maakt het mogelijk dat één enkele kwaadwillende tegenpartij elke node onder Windows, macOS of BSD laat crashen. Alle drie de punten zijn verholpen in de versies 29.5, 30.4, 31.2 en 32.1. Wie een eigen Bitcoin-node beheert en sinds maandag niet heeft bijgewerkt, draait op een versie waarvan de zwakke plekken sinds woensdag openbaar beschreven staan.

Een node is de computer die de hele blockchain zelf controleert in plaats van een aanbieder te vertrouwen. Valt hij uit, dan verdwijnt er geen saldo: de sleutels liggen in de wallet, niet in de node. Wat verloren gaat, is de eigen controle, en bij twee van de drie fouten gaat de computer eronder mee.

Drie meldingen op één dag: wat Bitcoin Core openbaar maakte

De drie publicaties staan samen in de meldingenlijst van het project. Twee ervan zijn als „Medium” ingeschaald, één als „Low”, en alle drie dragen de toevoeging „easily discoverable”, dus eenvoudig te vinden. Dat is de beslissende inschaling: wie de code leest, vindt de plek zonder bijzondere moeite.

• TCP-urgent-gegevens: een tegenpartij kan een node onder Windows, macOS of BSD laten crashen. Linux is niet getroffen.
• Gepauzeerde pre-BIP31-tegenpartijen: het geheugengebruik van een node groeit langzaam, maar zonder grens.
• Overloop van de undo-bestanden: een miner kan de herstelgegevens van andere nodes beschadigen.

De opeenvolging van de publicaties is ongewoon strak getimed. De correcties werden op 26 oktober doorgevoerd en teruggezet naar de takken 29, 30, 31 en 32. Op 27 oktober verschenen de versies 31.2 en 32.1, op 28 oktober volgden 29.5 en 30.4, en op dezelfde dag ging de beschrijving van de fouten online.

TCP-urgent-gegevens: waarom nodes op Windows en macOS crashen

Bitcoin Core beperkt hoeveel gegevens het per tegenpartij gereed houdt voor verwerking. Wordt de wachtrij te lang, dan pauzeert de software het lezen van die poort. Dat mechanisme heet tegendruk: de software remt de tegenpartij af in plaats van zelf vol te lopen.

Precies die rem laat zich omzeilen. Op systemen buiten Linux bewaakt Bitcoin Core de netwerkpoorten met een oudere techniek die ook reageert op zogenoemde uitzonderingstoestanden van een poort. Dat deed hij tot nu toe ook wanneer het lezen al lang gepauzeerd was. Een tegenpartij hoeft dus alleen TCP-urgent-gegevens te sturen, een zelden gebruikte vorm van overdracht buiten de normale volgorde, en de node leest verder. De wachtrij groeit zonder grens tot het werkgeheugen vol is.

Het project beschrijft het gevolg in zijn melding ondubbelzinnig: een kwaadwillende tegenpartij kan op deze manier elke verbonden node onder Windows, macOS of BSD laten crashen. Geen aanloop, geen voorbereiding, geen rekenkracht. De kwetsbaarheid werd op 23 oktober gemeld en de fout was drie dagen later verholpen.

Tegendruk: de rem die hier faalt

Dat dit überhaupt mogelijk was, komt door een bijzonderheid van de uitvoering. Onder Linux gebruikt Bitcoin Core een andere methode om netwerkpoorten te bewaken. Het foutieve pad bestaat daar simpelweg niet. Daarom blijven nodes op Linux-servers, op de meeste kant-en-klare nodekastjes voor thuis en in datacentra op dit punt onaangeroerd.

select() in plaats van poll(): Linux-nodes zijn niet getroffen

Voor de praktijk is dat het belangrijkste onderscheid van de hele dag. Wie zijn node op een singleboardcomputer of een kleine Linux-server laat lopen, valt bij deze fout buiten de boot. Wie Bitcoin Core daarentegen als programma op de werkcomputer beheert, dus onder Windows of op een Mac, hoort tot de getroffen groep. Hetzelfde geldt voor nodes op BSD-systemen.

Dat is geen theoretisch verschil. Een gecrashte node synchroniseert niet verder, antwoordt niet op vragen van de eigen wallet en meldt geen inkomende betalingen. Wie zijn wallet tegen de eigen node laat lopen, ziet in die tijd een verouderd saldo.

Pre-BIP31-tegenpartijen: 2 MB geheugen per uur en verbinding

De tweede fout werkt langzamer en is daarom verraderlijker. Bitcoin Core zet aankondigingen in de wachtrij voor alle tegenpartijen, ook voor de al gepauzeerde. Daartoe horen vooral de frequente meldingen over nieuwe transacties.

Normaal is dat onschuldig, omdat een tegenpartij wordt afgesloten als die twintig minuten lang niet op een controlebericht antwoordt. Dat controlebericht staat beschreven in BIP 31, een verbetervoorstel uit de begintijd van het netwerk dat het pingbericht een willekeurig getal meegeeft. Tegenpartijen die BIP 31 niet ondersteunen, worden van die afsluiting uitgezonderd. Een tegenpartij hoeft zich dus alleen oud voor te doen en het lezen doelbewust te vertragen.

Het project becijfert de toename precies: tot 2 MB per uur en inkomende verbinding, tot 5 MB per uur en uitgaande verbinding. Een node met veel inkomende verbindingen verzamelt op deze manier over dagen genoeg ballast om het werkgeheugen te vullen. Duidelijk minder getroffen zijn nodes die met de instelling -blocksonly lopen, omdat daar de transactiemeldingen wegvallen die het grootste deel van de wachtrij vormen.

Dit punt werd al op 15 september 2026 gemeld. Tussen melding en correctie lagen dus ruim zes weken waarin de kwetsbaarheid bij het project bekend was en bij het publiek niet.

Undo-bestanden boven 4 GiB: de derde fout in de rev-map

Het derde punt betreft een bestand waarvan de meeste nodebeheerders nog nooit hebben gehoord. Naast de blokbestanden legt Bitcoin Core zogenoemde undo-bestanden aan, te herkennen aan het naampatroon rev*.dat. Daarin staat welke munten een blok heeft uitgegeven. De software heeft die gegevens nodig wanneer een herschikking van de blockchain een al verwerkt blok weer moet losmaken.

Een herschikking, kort reorg, is het proces waarbij het netwerk omschakelt naar een andere, langere keten van blokken en eerder geldige blokken terugneemt. Blokbestanden zijn afgetopt op 128 MiB; de undo-bestanden hadden daarentegen nooit een bovengrens. De posities daarin werden als 32-bits getallen opgeslagen, en die reiken maar tot 4 GiB.

Een miner kan geldige blokken bouwen waarvan de undo-gegevens duidelijk groter zijn dan de blokken zelf. Groeit een undo-bestand voorbij die 4 GiB, dan springt de positieaanduiding terug naar het begin. Nieuwere undo-gegevens overschrijven oudere, en het bestand wordt tot de terugsprong ingekort. Maakt een latere herschikking een getroffen blok los, dan kan de node de undo-gegevens ervan niet meer lezen en sluit hij af. Opnieuw starten helpt niet. Het herstel vraagt een volledige herbouw van de index met een gecorrigeerde versie, op een gewone thuiscomputer een zaak van uren tot dagen.

32-bitssystemen en FAT32 blijven ook na de update kwetsbaar

Hier ligt het punt dat, anders dan de twee andere, niet volledig is afgehandeld. De overloop is verholpen doordat de posities nu als 64-bits getallen worden opgeslagen en Windows de passende bestandsopdrachten gebruikt. Het formaat op de schijf blijft onveranderd, een verhuizing van de gegevens is dus niet nodig.

Twee situaties blijven toch kwetsbaar. Op 32-bitssystemen werken de bestandsopdrachten nog steeds maar tot 2 GiB, daar treedt de fout dus al bij de helft van de hoeveelheid gegevens op, en wel zonder enige herschikking. En wie zijn blokmap op een FAT32-bestandssysteem heeft staan, bijvoorbeeld op een oudere externe schijf of een USB-stick, stuit op de bestandsgrens van dat formaat van 4 GiB. In beide gevallen mislukt het schrijven van de undo-gegevens en sluit de node bij elke start opnieuw af.

Praktisch uitbuiten laat de fout zich op 64-bitssystemen nauwelijks. Het project beschrijft de inspanning in detail: de benodigde transacties zijn niet standaardconform, een aanvaller zou meerdere duizenden van zulke blokken moeten delven, wat ongeveer overeenkomt met een maand blokproductie van het hele netwerk, en daarna zouden ongeveer achttien verdere blokken van hem precies aan het einde van een blokbestand van de doelnode moeten landen. Ten slotte zou hij een herschikking over twee blokken moeten winnen. Omdat de bestandsindeling van node tot node verschilt, raakt geen voorbereiding alle doelen.

Project Loupe: een automatische scan vond alle drie de kwetsbaarheden

Alle drie de fouten gaan terug op dezelfde bron. Ze werden gevonden door een geautomatiseerde scan met een taalmodel die onder de naam Project Loupe bij Spiral loopt en waarvoor Elias Rohrer verantwoordelijk is. Gregory Sanders controleerde de vondsten en meldde ze aan het veiligheidsteam van Bitcoin Core.

Twee van de drie punten werden daarnaast een tweede keer onafhankelijk ontdekt. Ontwikkelaar L0rinc meldde de geheugenfout bij gepauzeerde tegenpartijen op 21 september en de undo-overloop op 21 augustus, en Andrew Dorman de undo-overloop op 23 oktober. De correcties komen telkens van Antoine Poinsot.

Van embargo naar openbaarmaking: Bitcoin Core heeft de regels veranderd

Dat de beschrijvingen al een dag na de afgeronde versies openbaar stonden, is geen toeval. Het project heeft zijn publicatiepraktijk kort geleden omgegooid en de lange geheimhoudingstermijn opgegeven, waarover we op 23 oktober 2026 berichtten. De drie meldingen van 28 oktober zijn de eerste grotere ronde volgens de nieuwe lijn.

Voor beheerders heeft dat twee kanten. De kwetsbaarheden zijn sneller bekend, en wie niet bijwerkt, is sneller aanvalbaar. Tegelijk staat nu in na te lezen vorm wat er precies mis kan gaan, in plaats van alleen een versienummer met de aantekening „veiligheidsupdate”.

Zonder eigen node: waar je bitcoinsaldo dan ligt

Het grootste deel van de beleggers beheert geen eigen node. Wie zijn coins in een softwarewallet op de telefoon of de computer houdt, gebruikt de nodes van andere mensen, meestal die van de walletaanbieder. Welke wallet welke weg kiest en waar je je eigen controle kunt aanzetten, blijft per aanbieder verschillen.

Van de drie fouten is in deze groep niemand direct getroffen. Een risico blijft toch: valt de node van de aanbieder uit, dan zie je geen actueel saldo en wordt er geen betaling bevestigd. Je sleutels liggen daardoor onaangeroerd in de wallet, en dat is het hele punt van zelf bewaren.

De koers heeft niet op de publicatie gereageerd. Bitcoin noteerde op de ochtend van 29 oktober 2026 rond 79.790 dollar (CoinGecko) en daarmee ongeveer 1,6 procent onder de dag ervoor, in de pas met de rest van de markt na het rentebesluit van de Amerikaanse centrale bank van de dag daarvoor.

Bitcoin Core 32.1: wie op 32 bits blijft, blijft kwetsbaar

1. Versie controleren en wisselen. In de console toont bitcoin-cli getnetworkinfo de draaiende versie. Alles onder 29.5, 30.4, 31.2 of 32.1 hoort vervangen, vooral op Windows en macOS. Wil je de gelegenheid aangrijpen om de sleutels van je dagelijkse computer te scheiden, dan vind je de apparaten in de hardware wallet-vergelijking.
2. Bestandssysteem en architectuur bekijken. Ligt de blokmap op FAT32 of loopt de node op een 32-bitssysteem, dan blijft de derde fout open. Een verhuizing naar een modern bestandssysteem verhelpt hem. Wie in plaats daarvan helemaal op een aanbieder leunt, vergelijkt de kosten in het overzicht van aanbieders.
3. Geheugengebruik in de gaten houden. Groeit het gebruik van een oudere node over dagen gestaag, dan past dat bij de tweede fout. Met -blocksonly valt de toename duidelijk kleiner uit.

De volledige beschrijvingen staan in de meldingenlijst van Bitcoin Core, de tekst over de TCP-kwetsbaarheid in de bijbehorende afzonderlijke melding.

(Per 29 oktober 2026. Dit artikel is geen beleggingsadvies. Koersen en tarieven veranderen; controleer de voorwaarden bij de aanbieder voordat je koopt.)