Bitcoin Core ha pubblicato i dettagli di tre vulnerabilità di sicurezza a novembre 2026, circa un anno dopo che le correzioni erano già state rilasciate. La più grave delle tre, valutata High, poteva impedire ai nodi di mining di produrre template di blocco validi dopo una riorganizzazione della catena.

Bitcoin Core è l'implementazione di riferimento del protocollo Bitcoin. I nodi della rete si affidano a questo software open source per convalidare e inoltrare transazioni e blocchi, mentre i miner e i mining pool lo utilizzano per assemblare i template di blocco a partire dalle transazioni non confermate nella mempool, l'area della rete in cui sono in attesa le transazioni.

Per politica interna, il progetto divulga le vulnerabilità solo dopo un ritardo: la correzione viene prima distribuita in una release, e la descrizione tecnica segue solo quando le versioni interessate sono diventate obsolete. Le correzioni per queste vulnerabilità sono arrivate nelle versioni 30.0, 29.2 e 28.3, tutte rilasciate a ottobre 2025. Gli advisory portano gli identificativi CVE-2025-62861, CVE-2025-62859 e CVE-2025-62860 — gli identificativi standard con cui vengono catalogate le vulnerabilità software divulg pubblicamente. CVE-2025-62861 è valutata High; le altre due hanno valutazione Medium. Di conseguenza, il progetto ha pubblicato gli advisory appena 14 giorni dopo la fine del supporto per la linea 29.x, l'ultima serie di release vulnerabile. I testi completi sono disponibili nella divulgazione ufficiale e nell'indice degli advisory di sicurezza del progetto.

Come una riorganizzazione poteva bloccare i nodi di mining

La vulnerabilità di gravità alta, CVE-2025-62861, interessa le versioni da 28.0 a 28.2 e da 29.0 a 29.1. Niklas Goegge l'ha segnalata a settembre 2025. Il difetto affonda le radici in TRUC — acronimo di Topologically Restricted Until Confirmation — note anche come transazioni v3. Questa policy della mempool impone limiti rigidi a come le transazioni non confermate possono dipendere l'una dall'altra, e il suo scopo principale è aiutare i protocolli di layer-2 come la Lightning Network ad aumentare le commissioni dopo il fatto. La versione 28.0 ha aggiunto un'ulteriore regola denominata sibling eviction: una nuova transazione può tentare di aggiungere un secondo figlio a una transazione genitore TRUC e, se paga commissioni sufficienti, sostituisce il figlio esistente.

Il bug è emerso durante una riorganizzazione, o "reorg" — un evento in cui la rete sostituisce i blocchi aggiunti più di recente con una catena diversa. Bitcoin Core restituisce prima le transazioni dei blocchi disconnessi alla mempool con il flag bypass_limits=true. Il ramo della sibling eviction, tuttavia, non rispettava questo flag ed eseguiva comunque la sostituzione. Di conseguenza, la regola rimuoveva una transazione mentre i suoi discendenti rimanevano nella mempool, lasciando nella mempool transazioni che spendevano output inesistenti. Ogni volta che il nodo tentava quindi di costruire nuovi template di blocco, la verifica di validità falliva.

I miner interessati potevano produrre di nuovo template validi solo dopo aver riavviato il nodo, perché il riavvio ricarica la mempool in uno stato coerente. Ciò nonostante, l'advisory per CVE-2025-62861 non indica alcuna soluzione alternativa all'aggiornamento. Greg Sanders ha fornito la correzione con la PR #33504, che il progetto ha unito al ramo principale a ottobre 2025 e riportato nelle linee 28.x, 29.x e 30.x. La vulnerabilità riguardava solo la creazione dei template: poiché TRUC è una regola di mempool e non una regola di consenso, il bug non ha toccato il consenso. Le regole di mempool come TRUC sono policy locali che ogni nodo applica alle proprie transazioni in attesa, a differenza delle regole di consenso, che ogni nodo impone sulla catena condivisa.

Due vulnerabilità di gravità media riguardano l'inoltro dei blocchi e i peer Tor

CVE-2025-62859 interessa le versioni precedenti alla 29.2 e alla 30.0. Eugene Siegel aveva segnalato la vulnerabilità già ad aprile 2025. Riguarda la gestione dei compact block, il formato abbreviato che i nodi usano per trasmettersi i nuovi blocchi. Le versioni interessate azzeravano lo stato di download di tale blocco prima di verificare la witness malleation, termine che indica una modifica a posteriori dei dati witness. Se la verifica falliva, il nodo richiedeva nuovamente i dati allo stesso peer tramite GETDATA, con un timeout di 10 minuti — circa l'intervallo medio tra i blocchi di Bitcoin. Un peer malevolo che annunciava per primo un compact block poteva quindi ritardare l'elaborazione dei blocchi della vittima fino a 10 minuti. Inoltre, l'attaccante poteva ripetere l'attacco senza limiti in modalità -blocksonly o quando controllava tutti e tre i peer ad alta banda, il piccolo insieme di peer da cui un nodo dipende per gli annunci prioritari dei blocchi. La PR #32646, unita a giugno 2025, ha corretto il bug.

La seconda vulnerabilità di gravità media, CVE-2025-62860, interessa le versioni precedenti alla 28.3, alla 29.2 e alla 30.0. Martin Zumsande e Antoine Poinsot l'hanno segnalata a settembre 2025, due settimane prima che Goegge segnalasse la vulnerabilità alta. In Bitcoin Core, le connessioni Tor in ingresso compaiono con l'indirizzo IP del daemon Tor, il servizio locale che inoltra il traffico proveniente dalla rete di anonimato. Se tale indirizzo ricadeva in un intervallo IP consentito tramite -whitelist, tutti i peer Tor in ingresso ricevevano i permessi della whitelist. Questi permessi rimuovono i limiti DoS e le protezioni contro le fughe di informazioni sulla privacy.

Secondo l'advisory, "migliaia" di nodi mainnet raggiungibili avevano concesso questi diritti a tutte le connessioni Tor in ingresso. Spesso l'opzione era stata impostata da provider che distribuiscono Bitcoin Core insieme a un daemon Tor. Al contrario, la vulnerabilità non ha mai interessato i nodi privi di questa impostazione opzionale, non predefinita. Dalla PR #33395, Bitcoin Core non considera più i peer Tor in ingresso nell'assegnazione dei permessi della whitelist.

Il progetto valuta entrambe le vulnerabilità come Medium. Il ritardo nell'elaborazione dei blocchi era temporaneo, e gli attaccanti potevano ripeterlo a piacere solo in configurazioni specifiche, mentre la vulnerabilità Tor richiedeva una configurazione diversa da quella predefinita.

Perché è passato un anno tra la correzione e la divulgazione

Bitcoin Core separa deliberatamente la correzione dalla divulgazione. La correzione viene distribuita prima in una release regolare, e il progetto non descrive la vulnerabilità in quel momento; i dettagli seguono in seguito, quando le versioni interessate sono più datate o hanno raggiunto la fine del supporto. Questo dà tempo agli operatori di aggiornarsi.

Per i tre advisory attuali, le segnalazioni sono arrivate tra aprile e settembre 2025, e le correzioni sono entrate nel codice da giugno a ottobre 2025. Bitcoin Core 30.0, 29.2 e 28.3 sono poi stati rilasciati con le correzioni a ottobre 2025. La fine del supporto ha determinato i tempi della divulgazione: il supporto per la 29.x, l'ultima linea di versioni vulnerabile, è terminato il 27 ottobre 2026, e gli advisory sono seguiti il 10 novembre 2026 — 14 giorni dopo.

L'indice degli advisory del progetto utilizza quattro livelli di gravità: Critical, High, Medium e Low. Tutti e tre gli advisory si collocano sui livelli intermedi. Il periodo per CVE-2025-62859 spicca: Siegel ha segnalato la vulnerabilità ad aprile 2025, il progetto ha unito la correzione a giugno 2025, e i dettagli sono diventati pubblici solo poco più di 18 mesi dopo la segnalazione.

Cosa significano queste vulnerabilità per miner e operatori di nodi

La vulnerabilità alta riguardava principalmente i miner e i pool. Solo i nodi che attraversavano una reorg e dovevano poi costruire template di blocco attivavano il bug. Al contrario, le due vulnerabilità medie colpivano anche i nodi ordinari, ma richiedevano una situazione di rete o una configurazione specifica.

Le versioni 30.0 e 29.2 correggono tutti e tre i bug, e la 28.3 ne corregge due. Dalla fine di ottobre 2026, tuttavia, solo le versioni dalla 30.x in avanti ricevono supporto. Chiunque utilizzi la 29.x o versioni precedenti usa quindi software non supportato, anche con i backport.

Gli advisory lasciano aperte diverse domande. Ad esempio, non è chiaro se un attaccante possa creare deliberatamente la topologia di reorg che attiva il bug alto. Gli advisory non indicano nemmeno se qualcuno abbia mai sfruttato una delle tre vulnerabilità, e non esiste un conteggio esatto dei nodi interessati dalla vulnerabilità Tor. I documenti mostrano però che il progetto ha corretto e distribuito tutti e tre i bug poco più di un anno prima della divulgazione.