Bitcoin Core heeft in november 2026 details gepubliceerd over drie beveiligingskwetsbaarheden, ruim een jaar nadat de fixes voor deze lekken al waren uitgebracht. Het ernstigste van de drie, beoordeeld als Hoog, kon voorkomen dat mining-nodes na een chain reorganisatie geldige blocktemplates produceerden.

Bitcoin Core is de referentie-implementatie van het Bitcoin-protocol. Nodes in het netwerk gebruiken deze open-source software om transacties en blocks te valideren en door te sturen, terwijl miners en mining pools ermee blocktemplates opstellen vanuit onbevestigde transacties in de mempool, het wachtplaats van het netwerk voor lopende transacties.

Volgens projectbeleid worden kwetsbaarheden pas met vertraging openbaar gemaakt: de fix verschijnt eerst in een release, en de technische beschrijving volgt pas wanneer de getroffen versies verouderd zijn. De correcties voor deze lekken zijn terechtgekomen in versies 30.0, 29.2 en 28.3, die allemaal in oktober 2025 werden uitgebracht. De adviezen dragen de identificaties CVE-2025-62861, CVE-2025-62859 en CVE-2025-62860 — de standaardidentificaties waaronder openbaar gemaakte softwarekwetsbaarheden worden geregistreerd. CVE-2025-62861 is beoordeeld als Hoog; de andere twee dragen de beoordeling Middel. Het project publiceerde de adviezen daarom slechts 14 dagen nadat de ondersteuning voor de 29.x-lijn, de laatste kwetsbare releasereeks, was beëindigd. De volledige teksten zijn beschikbaar in de officiële openbaarmaking en in de index van beveiligingsadviezen van het project.

Hoe een reorganisatie mining-nodes kon lamleggen

Het lek met ernst Hoog, CVE-2025-62861, treft versies 28.0 tot en met 28.2 en 29.0 tot en met 29.1. Niklas Goegge meldde het in september 2025. Het defect vindt zijn oorsprong in TRUC — kort voor Topologically Restricted Until Confirmation — ook bekend als v3-transacties. Dit mempoolbeleg stelt strikte grenzen aan hoe onbevestigde transacties van elkaar afhankelijk mogen zijn, en het belangrijkste doel is om layer-2-protocollen zoals het Lightning Network in staat te stellen achteraf kosten te verhogen. Versie 28.0 voegde een extra regel toe genaamd sibling eviction: een nieuwe transactie kan proberen een tweede child toe te voegen aan een TRUC-oudertransactie, en als het genoeg aan transactiekosten betaalt, vervangt het het bestaande child.

De bug kwam aan het licht tijdens een reorganisatie, kortweg een "reorg" — een gebeurtenis waarbij het netwerk de meest recent toegevoegde blocks vervangt door een andere chain. Bitcoin Core zet eerst de transacties uit de losgekoppelde blocks terug in de mempool met de vlag bypass_limits=true. De sibling eviction-tak hield echter geen rekening met deze vlag en werd toch uitgevoerd. Hierdoor verwijderde de regel een transactie terwijl de afstammelingen ervan in de mempool bleven, waardoor de mempool transacties bevatte die outputs uitgaven die niet meer bestonden. Telkens wanneer de node daarna nieuwe blocktemplates probeerde op te stellen, faalde de geldigheidscontrole.

Getroffen miners konden alleen na het herstarten van de node weer geldige templates produceren, omdat een herstart de mempool in een consistente staat opnieuw laadt. Desondanks noemt het advies voor CVE-2025-62861 geen andere oplossing dan de update. Greg Sanders leverde de fix in PR #33504, die het project in oktober 2025 samenvoegde in de main branch en terugporteerde naar de 28.x-, 29.x- en 30.x-lijnen. Het lek trof alleen het aanmaken van templates: omdat TRUC een mempoolregel is en geen consensusregel, raakte de bug de consensus niet. Mempoolregels zoals TRUC zijn lokale beleidsregels die elke node toepast op zijn eigen lopende transacties, in tegenstelling tot consensusregels die elke node afdwingt op de gedeelde chain.

Twee lekken van gemiddelde ernst treffen blockrelay en Tor-peers

CVE-2025-62859 treft versies vóór 29.2 en vóór 30.0. Eugene Siegel meldde de kwetsbaarheid al in april 2025. Deze zit in de verwerking van compact blocks, het verkorte formaat waarmee nodes nieuwe blocks aan elkaar doorgeven. Getroffen versies wissen de downloadstatus van zo'n block voordat ze controleerden op witness-malleatie, een term voor een achterafwijziging van de witness-gegevens. Als deze controle faalde, vroeg de node de gegevens opnieuw op bij dezelfde peer via GETDATA, met een time-out van 10 minuten — ongeveer het gemiddelde interval tussen Bitcoin-blocks. Een kwaadaardige peer die als eerste een compact block aankondigde, kon daarmee de blockverwerking van het slachtoffer tot 10 minuten vertragen. Bovendien kon de aanvaller de aanval onbeperkt herhalen in -blocksonly-modus of wanneer het alle drie de high-bandwidth-peers controleerde, de kleine groep peers waarop een node vertrouwt voor prioritaire blockaankondigingen. PR #32646, samengevoegd in juni 2025, verholpe de bug.

Het tweede lek met ernst Middel, CVE-2025-62860, treft versies vóór 28.3, 29.2 en 30.0. Martin Zumsande en Antoine Poinsot meldden het in september 2025, twee weken voordat Goegge het lek met ernst Hoog rapporteerde. In Bitcoin Core verschijnen inkomende Tor-verbindingen onder het IP-adres van de Tor-daemon, de lokale service die verkeer vanuit het anonimiteitsnetwerk doorstuurt. Als dat adres binnen een via -whitelist toegestaan IP-bereik viel, kregen alle inkomende Tor-peers whitelist-rechten. Deze rechten heffen DoS-limieten en bescherming tegen privacy-lekken op.

Volgens het advies hadden "duizenden" bereikbare mainnet-nodes deze rechten toegekend aan alle inkomende Tor-verbindingen. Vaak hadden aanbieders die Bitcoin Core bundelen met een Tor-daemon de optie ingesteld. Daarentegen hebben nodes zonder deze optionele, niet-standaard instelling nooit last gehad van het lek. Sinds PR #33395 houdt Bitcoin Core geen rekening meer met inkomende Tor-peers bij het toekennen van whitelist-rechten.

Het project beoordeelt beide lekken als Middel. De vertraging in de blockverwerking was tijdelijk, en aanvallers konden deze alleen in specifieke opstellingen naar believen herhalen, terwijl het Tor-lek een configuratie vereiste die afweek van de standaard.

Waarom een jaar verstreek tussen fix en openbaarmaking

Bitcoin Core scheidt de fix bewust van de openbaarmaking. De correctie verschijnt eerst in een gewone release, en het project beschrijft de kwetsbaarheid op dat moment niet; details volgen later, zodra de getroffen versies ouder zijn of het einde van de ondersteuning hebben bereikt. Dit geeft beheerders tijd om te updaten.

Voor de drie huidige adviezen kwamen de meldingen binnen tussen april en september 2025, en de fixes werden tussen juni en oktober 2025 in de code opgenomen. Bitcoin Core 30.0, 29.2 en 28.3 verschenen vervolgens in oktober 2025 met de correcties. Het einde van de ondersteuning bepaalde het tijdstip van de openbaarmaking: de ondersteuning voor 29.x, de laatste kwetsbare versiereeks, eindigde op 27 oktober 2026, en de adviezen volgden op 10 november 2026 — 14 dagen later.

De adviesindex van het project gebruikt vier ernstniveaus: Kritiek, Hoog, Middel en Laag. Alle drie de adviezen zitten op de middelste niveaus. De periode voor CVE-2025-62859 valt op: Siegel meldde het lek in april 2025, het project voegde de fix in juni 2025 samen, en de details werden pas ruim 18 maanden na de melding openbaar.

Wat de lekken betekenen voor miners en node-beheerders

Het lek met ernst Hoog trof vooral miners en pools. Alleen nodes die een reorg doormaakten en daarna blocktemplates moesten opstellen, veroorzaakten de bug. Daarentegen troffen de twee lekken met ernst Middel ook gewone nodes, al vereiste elk een specifieke netwerksituatie of configuratie.

Versies 30.0 en 29.2 verhelpen alle drie de bugs, en 28.3 verhelpt er twee. Sinds eind oktober 2026 ontvangt echter alleen software vanaf versie 30.x nog ondersteuning. Wie 29.x of ouder draait, gebruikt dus niet-ondersteunde software, zelfs met de backports.

De adviezen laten meerdere vragen open. Zo is het onduidelijk of een aanvaller de reorg-topologie die het lek met ernst Hoog triggert, opzettelijk kan creëren. Ook staat niet in de adviezen of iemand ooit een van de drie lekken heeft uitgebuit, en er is geen exact aantal nodes bekend dat door het Tor-lek is getroffen. Uit het dossier blijkt wel dat het project alle drie de bugs ruim een jaar vóór de openbaarmaking heeft verholpen en uitgebracht.