Bitcoin Core schrapt het embargo: “the wrong tradeoff” bij makkelijk vindbare lekken

Bitcoin Core heeft de regels veranderd waarmee beveiligingslekken in de belangrijkste bitcoinsoftware openbaar worden. Wie een lek meldt dat met weinig moeite terug te vinden is, zet daarmee voortaan geen maandenlange stilte meer in gang, maar een point release voor elke nog onderhouden hoofdversie en een beveiligingsmelding op dezelfde dag. De wijziging is op 22 oktober 2026 om 16:06 uur opgenomen in het openbaarmakingsbeleid op bitcoincore.org.

Voor jou als houder van bitcoin is dat geen randnotitie uit de ontwikkelaarswereld. Het beleid bepaalt hoe snel een oplossing voor een fout in de software bij jou aankomt, en het bepaalt hoeveel voorsprong een aanvaller in de tussentijd heeft. Bij ongeveer 81.400 dollar per bitcoin op 23 oktober 2026 hangt aan die vraag de tegenwaarde van complete wallets.

Wat Bitcoin Core op 22 oktober aan het beleid heeft veranderd

Bitcoin Core is de referentiesoftware van het bitcoinnetwerk. Ze controleert blokken, houdt de blockchain bij en bepaalt mee welke transacties als geldig gelden. Wie een eigen node draait, gebruikt in de meeste gevallen precies deze software.

Het beleid onderscheidt naar eigen zeggen vier klassen kwetsbaarheden. Er is geen vijfde klasse bijgekomen, wel een kenmerk dat daar dwars op staat: Bitcoin Core kan een gemeld lek bij de eerste beoordeling als easily discoverable aanmerken, dus als makkelijk vindbaar. Hangt dat kenmerk aan een melding, dan vervalt de tot nu toe gebruikelijke wachttijd.

Het proces zelf is controleerbaar gedocumenteerd. Ontwikkelaar Antoine Poinsot diende de wijziging op 16 oktober 2026 in als pull request 1281, onder de titel "Update security policy for easy-to-find vulnerabilities". Na vijftien reacties werd ze op 22 oktober door een andere Core-beheerder samengevoegd. Er werd één bestand gewijzigd, met tien nieuwe en één geschrapte regel. Het gaat dus niet meer om een voorstel, maar om het geldende beleid.

"Easily discoverable": de nieuwe klasse in de bewoording van het beleid

Easily discoverable betekent in het beleid: een kwetsbaarheid die met minimale moeite te ontdekken is, bijvoorbeeld via een eenvoudige prompt aan een taalmodel. Dat is de hele definitie, en die is bewust ruim. De classificatie is uitdrukkelijk niet beperkt tot vondsten die werkelijk met een taalmodel zijn gedaan; de eenvoudige prompt dient als maatstaf voor de moeite, niet als voorschrift voor het gereedschap.

Draagt een melding dit kenmerk, dan geldt volgens het beleid: Bitcoin Core brengt voor elke onderhouden hoofdversie zo snel mogelijk een point release met de correctie uit, samen met een beveiligingsmelding, en past de anders gebruikelijke, van de ernst afhankelijke embargotermijnen niet toe. Een vooraankondiging twee weken voor de publicatie van de details blijft bestaan, maar alleen nog voor lekken die daadwerkelijk onder embargo staan.

Een jaar embargo tegenover een point release op dezelfde dag

Om te begrijpen hoe groot dit verschil is, loont een blik op de termijnen die daarnaast blijven gelden. Voor lekken zonder het nieuwe kenmerk blijft alles bij het oude.

Een kwetsbaarheid met lage ernst wordt twee weken na de publicatie van een hoofdversie met de correctie openbaar gemaakt. Bij gemiddelde en hoge ernst gebeurt dat pas twee weken nadat de laatste getroffen versie het einde van haar onderhoud heeft bereikt. Het beleid noemt dat moment zelf: ongeveer een jaar nadat een hoofdversie met de correctie voor het eerst is verschenen.

Daaruit volgt de eigenlijke hardheid van de oude regel, en het beleid benoemt die openlijk. Omdat Bitcoin Core op een lang embargo inzet, kunnen beveiligingscorrecties doorgaans niet naar oudere versies worden teruggezet. Ze bereiken de gebruikers pas met de volgende grote versie. Wie dus op een onderhouden, maar niet de nieuwste hoofdversie zat, kreeg een correctie soms maandenlang niet.

Antoine Poinsot noemt het embargo bij makkelijke vondsten de verkeerde afweging

Poinsot onderbouwt de stap met een afweging die in elk beveiligingsbeleid zit. Openbaarheid en tijd om bij te werken trekken in verschillende richtingen: openheid zet aanvallers en verdedigers op gelijke voet, maar kan een lek openbaar maken voordat de gebruikers hebben bijgewerkt. Bitcoin Core heeft vanwege de aard van het project en een trage updatecultuur voor het langere embargo gekozen.

Voor makkelijk vindbare fouten houdt die afweging volgens hem geen stand meer. Poinsot schrijft letterlijk dat dit "the wrong tradeoff" is, en vult aan: "The embargo period achieves little but it delays the availability of a fixed release." Het embargo bereikt dus weinig, maar vertraagt de beschikbaarheid van een gecorrigeerde versie. Als aanleiding noemt hij een toename van meldingen over lekken die makkelijk opnieuw te ontdekken zijn, en hij wijt dat eraan dat taalmodellen de drempel om bepaalde klassen fouten te vinden of verborgen correcties te herkennen flink verlagen.

Het tweede deel van die zin is het onaangenamere. Een stilletjes ingebouwde fix in de open broncode was vroeger moeilijk als zodanig te herkennen. Valt dat geautomatiseerd op te sporen, dan verraadt het embargo het lek zelf, terwijl het dat juist probeert te verbergen.

LLM's verlagen de drempel, de red-team-ronde laat het in cijfers zien

Hoe sterk de situatie is verschoven, laat een ronde zien waarover CoinDesk op 23 oktober 2026 berichtte. Een vrijwilligersgroep met de naam Bitcoin Red Team, volgens dat bericht zestien ontwikkelaars, liet eind juli 2026 AI-modellen over 390 bitcoinprojecten lopen, volgens het bericht in ongeveer een dag. Er werden 4.962 bevindingen vastgelegd, waarvan 85 als kritiek aangemerkt.

Die cijfers zijn ruwe bevindingen en geen bevestigde lekken, en de berichten over de ronde lopen uiteen; één weergave noemt slechts ongeveer een vijfde van de bevindingen als bevestigd. Als orde van grootte blijft het punt toch staan: wat vroeger weken handwerk van een specialist kostte, loopt nu in één nacht en in de breedte.

Dat daaruit schade ontstaat, is volgens hetzelfde bericht aangetoond. Een kwetsbaarheid in BTCPay Server die de groep eerder vertrouwelijk had gemeld, werd volgens het bericht binnen enkele dagen op draaiende servers van handelaren misbruikt en trok Lightning-nodes leeg. Core Lightning vroeg zijn operators in augustus 2026 verbindingen te verbreken, nadat AI-gegenereerde meldingen aan het kleine team echt bleken te zijn. Menselijke controle blijft daarbij nodig, want een deel van de machinaal gegenereerde meldingen beschrijft uiteindelijk helemaal geen kwetsbaarheid.

Dat een lek niet door een taalmodel gevonden hoeft te worden om duur uit te pakken, laat een geval uit dezelfde zomer zien. In de firmware van hardware wallet Coldcard sluimerde volgens het bericht sinds 2021 een fout waarmee op 30 juli 594 bitcoin in 25 minuten werden weggesluisd; over vier opnames liep het verlies op tot bijna 114 miljoen dollar. Wie de modellen van verschillende aanbieders en hun updateroutes wil vergelijken, vindt het overzicht in de vergelijking van hardware wallets.

Drie hoofdversies gelden als onderhouden: 29.x, 30.x en 31.x

"Elke onderhouden hoofdversie" is de beslissende bijzin van de nieuwe regel, want die vertelt je of een point release jou überhaupt bereikt. Bitcoin Core houdt zich daarbij aan een beknopte toezegging: onderhouden worden altijd de laatste drie hoofdversies, zo staat het in het levenscyclusplan van het project op bitcoincore.org.

Op dit moment zijn dat drie versies. Versie 31.x verscheen op 19 april 2026 en is de actuele uitgave. Versie 30.x dateert van 10 oktober 2025, versie 29.x van 14 april 2025. Het einde van het onderhoud is telkens gekoppeld aan de komende hoofdversies en niet aan een vaste datum. Versie 28.x viel op 19 april 2026 buiten het onderhoud en krijgt daarmee ook geen point release onder de nieuwe regel.

Zo controleer je welke Core-versie je eigen node draait

Als je een eigen node draait, is het versienummer het enige gegeven dat over jouw situatie beslist. Het staat in de interface van Bitcoin Core onder het menu-item met de programma-informatie, en op de opdrachtregel levert de aanroep bitcoin-cli -version het op. Ligt het eerste getal onder 29, dan val je buiten het onderhoud en bereikt geen van de hier beschreven correcties jou.

Twee andere punten zijn nu belangrijker dan voorheen. Ten eerste loont het om de beveiligingsmeldingen van het project te volgen, omdat melding en gecorrigeerde versie voortaan op dezelfde dag verschijnen en de voorsprong in tijd ontbreekt. Ten tweede is de reactietijd in je nadeel korter geworden: met de publicatie zijn de details openbaar, en wie niet bijwerkt, draait door met een bekend lek. Hetzelfde principe geldt voor de software wallet op je computer of telefoon, waarvan je de updateroutes in vergelijkingen van software wallets naast elkaar kunt zetten.

Voor houders zonder eigen node verschuift de verantwoordelijkheid

De overgrote meerderheid van de beleggers draait geen eigen node. Voor hen werkt de wijziging indirect, namelijk via de diensten die Bitcoin Core op de achtergrond draaien. Daartoe horen exchanges, bewaarders, betaaldienstverleners en de servers achter sommige wallet-apps.

Daar is de nieuwe regel in eerste instantie goed nieuws. Een operator die tot nu toe op een grote versie moest wachten, krijgt de correctie nu als point release voor de versie die hij toch al draait. Dat verlaagt de drempel om überhaupt bij te werken. Tegelijk stijgt de druk om het snel te doen, omdat de details van het lek op hetzelfde moment openbaar worden.

Hardware wallets en exchanges hangen aan dezelfde openbaarmaking

Er hoort een kanttekening bij, zodat de reikwijdte van deze wijziging niet wordt overschat. Ze betreft Bitcoin Core, niet de hele bitcoingereedschapskist. Hardware wallets, wallet-apps, betaalservers en Lightning-implementaties hebben elk een eigen beleid, en de gevallen uit deze zomer komen grotendeels uit precies die projecten. De vraag hoe snel een aanbieder firmware en app bijwerkt, blijft een vraag aan de aanbieder.

Voor jou betekent dat: de keuze of je zelf bewaart of laat bewaren, verschuift alleen wie het bijwerken op zich neemt. Ze neemt de taak niet weg. Wie zelf bewaart, draagt het versiebeheer voor node en wallet. Wie bij een bewaarder zit, vertrouwt erop dat diens techniek de point releases snel doorvoert, en ruilt controle in voor uitbesteding.

Eén punt staat nog open. Tot 23 oktober 2026 was volgens het bericht van CoinDesk nog geen enkel lek onder de nieuwe regel ingedeeld. Hoe kort "zo snel mogelijk" in de praktijk uitvalt, zal pas bij het eerste echte geval blijken. Ook Poinsot erkent dat zulke correcties minder tijd hebben om te rijpen voordat ze de gebruikers bereiken. Een voorstel om de beveiligingsmelding helemaal achterwege te laten, wees hij daarentegen af: gebruikers over een lek informeren zonder details te noemen, kan onnodig extra risico opleveren.

Bitcoin Core: point release en advisory komen op dezelfde dag

1. Versienummer vaststellen. Controleer bij een eigen node of het eerste getal 29, 30 of 31 is. Ligt het lager, werk dan bij naar een onderhouden versie. Voor de walletkant helpt een vergelijking van software wallets bij de vraag hoe de aanbieder zijn updates uitlevert.
2. Firmware van de hardware wallet bijwerken. Het Coldcard-lek zat volgens het bericht vier jaar in de firmware. Controleer wanneer je voor het laatst hebt bijgewerkt en hoe jouw model updates überhaupt krijgt; de vergelijking van hardware wallets zet de aanbieders naast elkaar.
3. Verantwoordelijkheid regelen. Beslis wie bij jou het bijwerken op zich neemt. Staat een deel van je bezit bij een bewaarder, controleer dan diens informatie over de techniek; een overzicht van aanbieders vind je in onze vergelijking om crypto te kopen.

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