Bitcoin koers: Tor-whitelistlek in Bitcoin Core, duizenden nodes behandelden vreemden als vertrouwd

Bitcoin Core heeft op 10 november 2026 opnieuw drie kwetsbaarheden openbaar gemaakt. De ingrijpendste treft nodes die Bitcoin Core samen met de anonimiseringsdienst Tor draaien: wie de optie -whitelist voor een IP-bereik had ingesteld, behandelde tot de versies 28.3, 29.2 en 30.0 ook elke inkomende Tor-verbinding als vertrouwde peer. Volgens de ontwikkelaars ging het om duizenden bereikbare nodes op het hoofdnetwerk. Alle drie de fouten zijn al meer dan een jaar verholpen; wie zijn node bijhoudt, is beschermd. Wie nog een versie van vóór 30.0 draait, doet er goed aan nu bij te werken, want met 29.x viel de laatste getroffen versiereeks op 27 oktober buiten het onderhoud.

Bitcoin Core is de referentiesoftware van het Bitcoin-netwerk. Een node is een computer die deze software uitvoert, elk blok zelf controleert en transacties doorgeeft aan andere nodes. Wie een eigen node draait, hoeft voor zijn saldo niet op servers van anderen te vertrouwen. Hoeveel moeite en stroom dat kost, hebben we doorgerekend in ons overzicht een eigen Bitcoin-node draaien.

Bitcoin Core: drie openbaarmakingen op 10 november

De drie meldingen dragen de kenmerken CVE-2025-62859, CVE-2025-62860 en CVE-2025-62861. Een CVE-nummer (Common Vulnerabilities and Exposures) is een wereldwijd uniek kenmerk voor een bekend geworden kwetsbaarheid. Bitcoin Core deelt twee van de drie fouten in als middelzwaar en één als zwaar. Het verloop volgt de openbaarmakingsregel van het project: een lek wordt pas publiek beschreven als de laatste getroffen versiereeks geen onderhoud meer krijgt.

Die drempel is sinds 27 oktober 2026 bereikt. Toen eindigde het onderhoud voor Bitcoin Core 29.x, nadat op 27 oktober versie 32.1 was verschenen. Op 28 oktober volgden de onderhoudsversies 31.2, 30.4 en 29.5, en diezelfde dag maakte het project al drie andere fouten bekend, waarover we schreven in ons artikel drie kwetsbaarheden in Bitcoin Core. De nieuwe meldingen zijn de tweede ronde binnen twee weken, maar ze betreffen andere onderdelen van de software.

Gemeen hebben de drie gevallen dat externe ontwikkelaars de fouten vonden en vertrouwelijk meldden bij de beveiligingslijst van het project. De correcties werden stilletjes opgenomen in de versies 28.3, 29.2 en 30.0, die tussen 10 en 20 oktober 2025 verschenen. Pas nu, ruim een jaar later, worden ze publiek beschreven.

Tor-whitelist in Bitcoin Core: waarom Tor-verbindingen als vertrouwd golden

De fout met kenmerk CVE-2025-62860 zit in een instelling die veel thuisgebruikers nooit zelf hebben ingesteld. Met -whitelist markeert een beheerder bepaalde peers als vertrouwd. Voor hen heft Bitcoin Core volgens de beveiligingsmelding van het project verschillende limieten tegen overbelastingsaanvallen op en versoepelt het beschermingsmaatregelen die moeten voorkomen dat informatie over de node naar buiten lekt. Dat is bedoeld voor eigen apparaten in het thuisnetwerk, zoals een tweede computer of wallet-software die rechtstreeks met de node communiceert.

Het probleem ontstaat door de manier waarop Tor verbindingen aflevert. Een vreemde computer die via Tor een node bereikt, verschijnt voor Bitcoin Core niet met zijn eigen adres. Zichtbaar is alleen het adres van de Tor-dienst, en die draait meestal op hetzelfde apparaat of in hetzelfde thuisnetwerk. Lag dat adres in het IP-bereik dat de beheerder met -whitelist had vrijgegeven, dan belandde elke inkomende Tor-verbinding op de lijst met vertrouwde peers. Een willekeurige deelnemer van internet kreeg zo dezelfde rechten als het eigen apparaat in de woonkamer.

Verholpen is dit in Bitcoin Core 30.0 en alle latere versies, en vanaf de onderhoudsversies 28.3 en 29.2. Sindsdien krijgen inkomende Tor-verbindingen die binnenkomen via een speciaal voor Tor ingericht adres (onion bind) nooit whitelist-rechten. Nodes die de optie -whitelist nooit hadden ingesteld, waren volgens de ontwikkelaars op geen enkel moment getroffen.

Het lek werd gevonden door de Bitcoin Core-ontwikkelaars Martin Zumsande en Antoine Poinsot. Zij meldden de fout op 12 september 2025 bij het beveiligingsteam. De correctie werd op 17 september 2025 doorgevoerd en overgenomen in oudere versiereeksen. Dezelfde dag lichtte Poinsot volgens de melding ook Luke Dashjr in, die de alternatieve nodesoftware Bitcoin Knots onderhoudt, en op 19 september meerdere getroffen softwareleveranciers.

Kant-en-klare Bitcoin-nodes: waar de duizenden getroffen nodes vandaan kwamen

Dat het lek zo breed doorwerkte, kwam door een gewoonte in de sector. Volgens de beveiligingsmelding leverden veelgebruikte aanbieders Bitcoin Core samen met een Tor-dienst en zetten zij de optie -whitelist af fabriek op een IP-bereik waarin ook de Tor-dienst lag. Daarbij kwam dat aanvullende software die op Bitcoin Core voortbouwt, de whitelist-instelling nodig had om te werken. Die programma's draaien vaak naast een Tor-dienst. Het resultaat beschrijven de ontwikkelaars zo: duizenden bereikbare nodes op het hoofdnetwerk zetten elke inkomende Tor-verbinding op de whitelist.

Voor veel thuisgebruikers is dat een bekend beeld. Kant-en-klare nodepakketten voor kleine computers bundelen Bitcoin Core, Tor, een server voor wallet-opvragingen en vaak ook Lightning-software onder één grafische interface. Het configuratiebestand krijgt de gebruiker zelden te zien. Of een bepaald pakket getroffen was, vermeldt de melding niet; de fabrikanten zijn ruim een jaar geleden ingelicht. Wie zo'n pakket gebruikt, vindt de geïnstalleerde Bitcoin Core-versie doorgaans in het app-overzicht of in de release notes van het pakket.

Belangrijk is het verschil tussen het pakket en de Bitcoin Core-versie die erin zit. Een pakket kan net zijn bijgewerkt en toch een oudere Bitcoin Core-versie meeleveren, als die ene app niet is bijgewerkt. Voor de drie lekken telt alleen het versienummer van Bitcoin Core.

CVE-2025-62859 in Bitcoin Core: Compact Blocks en tien minuten wachten

Het tweede middelzware lek betreft de manier waarop nodes nieuwe blokken zuinig uitwisselen. Compact Blocks is een methode waarbij een node niet het hele blok verstuurt, maar alleen korte kenmerken van de transacties erin. De ontvanger stelt het blok samen uit transacties die hij toch al in zijn tussengeheugen heeft. Dat bespaart bandbreedte en versnelt de verspreiding van nieuwe blokken over het netwerk.

Bitcoin Core vóór de versies 29.2 en 30.0 ruimde na het samenstellen van zo'n blok zijn downloadstatus op voordat het controleerde op een bepaalde manipulatie van de handtekeningdata (witness malleation). Mislukte die controle, dan vroeg de node het blok opnieuw op, bij dezelfde peer en met een wachttijd van tien minuten. Een aanvaller die een node als eerste een nieuw blok aankondigt, kon zo de blokverwerking van die node ophouden.

Eindeloos herhaalbaar was de aanval onder twee voorwaarden die de melding noemt: als de aanvaller alle drie de peers beheerste die de node voor snelle blokoverdracht gebruikt, of als de node in de modus -blocksonly draaide en dus alleen blokken en geen losse transacties doorgeeft. De fout werd ontdekt door ontwikkelaar Eugene Siegel en gemeld op 28 april 2025. De correctie van Gregory Sanders werd op 30 juni 2025 overgenomen.

Voor een thuisnode betekent zo'n stilstand vooral dat hij achterloopt op nieuwe blokken. De wallet die eraan hangt, toont inkomende betalingen dan later. Wie bitcoin ontvangt en de ontvangst via de eigen node bevestigt, ziet in het slechtste geval een verouderde stand.

CVE-2025-62861: TRUC-transacties leggen miners stil na een reorganisatie

Het enige als zwaar ingedeelde lek treft vooral miners. TRUC staat voor Topologically Restricted Until Confirmation en verwijst naar transacties van versie 3 volgens BIP 431. Daarvoor gelden tot de bevestiging strengere regels: hoogstens één onbevestigde voorganger en hoogstens één onbevestigde opvolger. Die regels gelden alleen voor het tussengeheugen van een node (mempool), niet voor de consensusregels. Een geldig blok mag dus best anders zijn opgebouwd.

Sinds versie 28.0 kent Bitcoin Core een vervangingsregel voor deze transacties, de zogeheten sibling eviction. Krijgt een TRUC-transactie een tweede onbevestigd kind, dan verdringt het nieuwe kind het oude als het genoeg transactiekosten betaalt. Bij een reorganisatie, dus wanneer een node overstapt op een langere concurrerende reeks blokken, zet Bitcoin Core de transacties uit de verworpen blokken terug in de mempool. Daarbij liep de verdringingsregel ten onrechte mee.

Het gevolg volgens de melding: in de mempool bleven transacties achter die outputs gebruikten die daar niet meer bestonden. Een miner van wie de node zo'n reorganisatie meemaakte, kon geen geldig blokvoorstel meer maken totdat hij de node herstartte. Getroffen zijn de versies 28.0 tot en met 28.2 en 29.0 tot en met 29.1; verholpen is de fout in Bitcoin Core 30.0 van 10 oktober 2025. Niklas Gögge meldde hem op 26 september 2025.

Ernst hoog en middel: zo deelt Bitcoin Core de drie lekken in

Bitcoin Core deelt elke gemelde kwetsbaarheid in een van vier klassen in, die het project beschrijft op zijn pagina met beveiligingsmeldingen. Als kritiek gelden fouten die de veiligheid van het hele netwerk bedreigen, zoals diefstal van coins op protocolniveau, het aanmaken van coins buiten het vastgelegde uitgifteschema of een blijvende splitsing van het netwerk. Geen van de drie nieuwe lekken valt in die klasse.

Zwaar (High) zijn fouten met aanzienlijke gevolgen voor getroffen nodes of het netwerk, die doorgaans op afstand en met standaardinstellingen te misbruiken zijn. Middelzwaar (Medium) zijn fouten die prestaties of werking merkbaar aantasten, maar waarvan het bereik of de misbruikbaarheid beperkt is. Voor het Tor-lek betekent dat: de fout werkte alleen bij een ingestelde whitelist, maar dan wel bij heel veel nodes tegelijk.

De indeling helpt bij de vraag hoe dringend een update is. Een thuisnode die geen blokken maakt, merkt praktisch niets van het zware TRUC-lek, want dat raakt het maken van blokvoorstellen. Voor thuisgebruikers zijn de twee middelzware lekken belangrijker, omdat ze de privacy en de bereikbaarheid van de eigen node betreffen.

Bitcoin Core 29.x buiten onderhoud: sinds 27 oktober geen beveiligingsupdates

Volgens zijn eigen levenscyclusregel onderhoudt het project steeds de drie jongste hoofdversies. Sinds versie 32.0 zijn dat 32.x, 31.x en 30.x. Hoofdversies die uit dat venster vallen, krijgen doorgaans geen beveiligingscorrecties meer. Actueel zijn de versies 32.1 van 27 oktober en 31.2 en 30.4 van 28 oktober 2026.

Wie nog een 29-versie draait, heeft voor de drie nieuwe lekken met 29.5 wel een gecorrigeerde versie, maar krijgt voortaan geen correcties meer. Overstappen op een onderhouden hoofdversie is daarom de nettere weg. Voor een grote versiesprong loont het om de release notes te lezen, omdat standaardinstellingen kunnen veranderen.

De eigen versie toont het commando bitcoin-cli --version of de uitvoer van bitcoin-cli getnetworkinfo in het veld subversion, waar bijvoorbeeld /Satoshi:30.4.0/ staat. In de grafische interface Bitcoin-Qt vind je de gegevens onder Help en Info. Bij kant-en-klare pakketten staat de versie meestal in het overzicht van geïnstalleerde apps.

Whitelist van Bitcoin Core in bitcoin.conf: welke regels opvallen

Los van de versie is het zinvol het configuratiebestand bitcoin.conf te bekijken. Regels die beginnen met whitelist= geven peers bijzondere rechten. Staat daar een heel IP-bereik, bijvoorbeeld een netwerk van de thuisrouter of een intern containernetwerk, dan moet je weten welke apparaten daarin zitten en of er een Tor-dienst bij hoort. Wie het bestand niet zelf heeft aangemaakt, komt er bij kant-en-klare pakketten vaak alleen via uitgebreide toegang tot de computer bij.

Vanaf Bitcoin Core 30.0, 29.2 en 28.3 behandelt de software inkomende Tor-verbindingen die via het speciaal daarvoor ingerichte adres binnenkomen, sowieso niet meer als vertrouwd. Met een actuele versie is de kern van het lek dus gedicht, ook als de whitelist-regel ongewijzigd blijft. Een krap gehouden whitelist blijft toch goede praktijk, omdat elke uitzondering beschermingslimieten opheft.

Bitcoin-tegoed en wallet: waarom de lekken geen coins kosten

Het goede nieuws voor beleggers die vooral de bitcoin koers volgen: volgens de indeling van het project maakte geen van de drie lekken het mogelijk coins te stelen of nieuwe aan te maken. De private keys staan bij de meeste thuisgebruikers sowieso in een aparte wallet en helemaal niet in de node zelf. Wie zijn tegoed op een hardware wallet bewaart en de node alleen als eigen controle-instantie gebruikt, scheidt sleutels en netwerksoftware netjes. Welke apparaten daarvoor in aanmerking komen, zie je in onze vergelijking van hardware wallets.

De risico's lagen bij bereikbaarheid en privacy. Een peer met whitelist-rechten heeft minder limieten tegen overbelasting en krijgt informatie die de node voor vreemden normaal achterhoudt. Voor gebruikers die Tor juist vanwege de anonimiteit inzetten, is dat het gevoeligste punt. Een node die achterloopt op nieuwe blokken, toont bovendien inkomende betalingen te laat.

Wie geen eigen node draait, is niet rechtstreeks getroffen door de drie lekken. Software-wallets op de smartphone vragen doorgaans servers van de aanbieder op, en exchanges bewaren de coins van hun klanten op hun eigen infrastructuur. Een overzicht van wallets die zonder eigen node werken, vind je in onze vergelijking van software-wallets.

Lekken in Bitcoin Core: vanaf versie 30 zijn alle drie gedicht

De drie openbaarmakingen van 10 november beschrijven fouten die sinds oktober 2025 zijn verholpen. Risico loopt wie een node met een oudere versie draait en de update al een jaar voor zich uitschuift. Drie stappen volstaan:

1. Versie controleren en bijwerken: zit je node onder 30.0, stap dan over op een onderhouden hoofdversie zoals 30.4, 31.2 of 32.1. Wie zijn coins alleen bij een beurs aanhoudt, heeft geen eigen node nodig; betrouwbare aanbieders vind je in onze vergelijking van de beste crypto-exchanges.
2. Whitelist inkorten: loop in bitcoin.conf elke regel met whitelist= na en beperk die tot de apparaten die je echt kent. Voor wallet-opvragingen zonder eigen node helpt onze vergelijking van software-wallets.
3. Sleutels loskoppelen van de node: bewaar grotere tegoeden op een hardware wallet en gebruik de node alleen voor controle. Geschikte apparaten staan in de vergelijking van hardware wallets.

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