Bitcoin Core ha pubblicato la divulgazione ufficiale di CVE-2025-62861, un difetto ad alta gravità nella logica di relay delle transazioni del software del nodo che avrebbe potuto lasciare le operazioni di mining impegnate nell'hashing su template di blocco obsoleti senza alcun segnale visibile. L'advisory attribuisce la segnalazione al ricercatore di sicurezza Niklas Goegge e riconduce il problema a una regola di relay attivata nell'momento sbagliato: durante una riorganizzazione della catena, quando avrebbe dovuto restare silente.

Le versioni interessate vanno da Bitcoin Core 28.0 a 28.2 e da 29.0 a 29.1. La correzione è stata rilasciata a ottobre 2025, ma i dettagli tecnici completi sono stati trattenuti fino a novembre 2026 secondo la politica di divulgazione coordinata del progetto. L'advisory non cita alcuna interruzione di servizio né alcun operatore interessato; l'esposizione è storica. L'hardware di mining puntato su un nodo in questo stato corrotto avrebbe continuato a eseguire l'hashing, ma sull'ultimo template ricevuto, così le nuove transazioni e le loro commissioni sarebbero rimaste non rivendicate finché qualcuno non se ne fosse accorto.

Come una riorganizzazione può rendere orfana una transazione

Una riorganizzazione si verifica quando un nodo abbandona la propria punta di catena attuale per un ramo concorrente più pesante. Le transazioni nei blocchi disconnessi rimangono valide, quindi Bitcoin Core le reinserisce nella mempool, l'area di attesa per le transazioni non confermate. Poiché quelle transazioni erano già state confermate in un blocco valido, il nodo le riaggiunge con un flag chiamato bypass_limits, che disattiva i consueti controlli anti-spam e di topologia. Lo scopo è ripristinare fedelmente il pool, non rivalutare transazioni che hanno già superato il consenso.

Uno dei controlli che avrebbero dovuto essere disattivati riguarda le transazioni di versione tre, ovvero TRUC. Secondo BIP 431, una transazione TRUC può avere al massimo un genitore non confermato e un figlio non confermato. Si tratta di una politica di relay, non di una regola di consenso: un blocco può legittimamente contenere un genitore TRUC con più figli, anche se nessun nodo accetterebbe tale struttura nella propria mempool dalla rete. Quella stessa linea di demarcazione tra politica e consenso ha definito il confine del bug stesso: CVE-2025-62861 poteva corrompere la mempool di un nodo e bloccare la produzione di template, ma non poteva creare un blocco invalido né alterare le regole della catena.

Dalla versione 28.0, Bitcoin Core applica il limite di un solo figlio tramite un meccanismo chiamato sibling eviction. Quando una nuova transazione darebbe a un genitore TRUC un secondo figlio non confermato, il nodo tratta il figlio esistente come candidato alla sostituzione e, se la nuova transazione paga commissioni sufficienti, lo espelle secondo le regole replace-by-fee.

Il bug consisteva nel fatto che la sibling eviction veniva eseguita anche quando bypass_limits era impostato. Una riorganizzazione che ripristinasse un genitore TRUC con più figli — una struttura perfettamente valida all'interno del blocco disconnesso — poteva innescare l'espulsione di una transazione ripristinata, lasciando nel pool le transazioni che ne spendevano gli output. La mempool conteneva così figli il cui genitore non esisteva più da nessuna parte: né nella catena, né nel pool.

La correzione di Greg Sanders ha condizionato i controlli TRUC a bypass_limits, così l'espulsione non viene più eseguita durante il ripristino dopo una riorganizzazione. La pull request associata, PR #33504, ha anche aggiunto lo scenario di test che mancava nel codice originale: transazioni provenienti da blocchi disconnessi anziché da peer.

L'aspetto di un template bloccato dal lato del mining

Un nodo affida il lavoro al software di mining tramite getblocktemplate, che assembla un blocco candidato, lo sottopone al controllo di validità interno del nodo e restituisce l'hash del blocco precedente, le transazioni selezionate e l'altezza successiva. Con una transazione priva di genitore nel pool, il candidato assemblato non superava tale controllo, quindi la chiamata non poteva restituire lavoro aggiornato.

Dall'esterno, il nodo appariva sano:

• Processo in esecuzione
• Connessioni ai peer aperte
• Punta di catena in avanzamento
• Mempool che accetta nuove transazioni

Ciò che era in realtà rotto:

• La richiesta di template restituisce un errore
• Gli hasher continuano a lavorare su lavoro obsoleto
• Nessun blocco può essere trovato sulla punta attuale
• Lo stato persiste finché il nodo non viene riavviato

Tutto ciò che una generica dashboard di monitoraggio osserva sarebbe rimasto verde. Nemmeno la rete forniva segnali: la punta di catena continuava ad avanzare — i blocchi venivano ancora trovati, solo non da questa operazione — così il costo ricadeva solo sul miner bloccato, sotto forma di hashing incapace di produrre un blocco sulla punta attuale e di commissioni che avrebbe altrimenti rivendicato. L'unica cosa di cui un miner ha bisogno dal nodo — un template aggiornato — era proprio la cosa che aveva smesso di produrre.

Riavvio, patch e fine del ciclo di vita

Il riavvio del nodo ricarica la mempool dal disco in uno stato coerente, il che elimina il sintomo. Non fa nulla riguardo alla causa: la successiva riorganizzazione con la stessa struttura di transazioni potrebbe bloccare nuovamente il nodo.

Il difetto sottostante è stato rimosso in tre release. La versione 30.0 è stata rilasciata con la correzione il 10 ottobre 2025, seguita dai backport in 29.2 e 28.3. Dalla segnalazione privata all'ultima di quelle release sono trascorse tre settimane:

Entrambi i rami di backport hanno successivamente lasciato il supporto. La politica di manutenzione di Bitcoin Core copre le tre versioni maggiori più recenti — attualmente 30.x, 31.x e 32.x — e la serie 29.x ha raggiunto la fine del ciclo di vita il 27 ottobre 2026. Un operatore che ha risposto al guasto originale con un semplice riavvio ora esegue codice non più supportato, con una descrizione pubblica di quale struttura di transazioni lo innesca esattamente.

Perché l'advisory ha atteso 396 giorni

Dalla prima release corretta all'advisory dettagliato sono trascorsi 396 giorni, e la divulgazione è arrivata esattamente due settimane dopo che la serie 29.x ha raggiunto la fine del ciclo di vita. Nessuno dei due numeri è una coincidenza. La politica di divulgazione di Bitcoin Core trattiene i dettagli di gravità media e alta fino a due settimane dopo che l'ultima release interessata non è più supportata, con un pre-annuncio due settimane prima, sincronizzato con il rilascio di una nuova versione maggiore.

L'embargo copriva la spiegazione, non il codice. La pull request è pubblica dal 29 settembre 2025, e le note di rilascio della 28.3 e della 29.2 elencavano all'epoca una correzione alla mempool. Ciò che è rimasto privato per un anno è stato il documento che collega la patch a un blocco del mining riproducibile.

La politica prevede comunque una via più rapida. I bug classificati come easily discoverable — che il progetto definisce individuabili con sforzo minimo — ricevono una point release e un advisory immediati, senza embargo. Questo caso ha seguito il calendario standard, quindi i maintainer non lo consideravano banale da trovare. È stato pubblicato lo stesso giorno insieme ad altri due advisory di gravità alta e media, riguardanti un blocco dell'elaborazione dei blocchi e un errore di permessi Tor; tutti e tre sono stati corretti nello stesso ciclo di rilascio di ottobre 2025. Qualsiasi build abbastanza recente da contenere la patch alla mempool contiene quindi anche le altre due correzioni.

La via più lenta incarna una propria ipotesi: che gli operatori aggiornino entro la finestra di un anno, così che, quando l'innesco viene descritto pubblicamente, nessun soggetto vulnerabile stia ancora ascoltando.

Cosa monitorare al posto dell'uptime

Per un'operazione di mining, il controllo utile non è se il nodo sia vivo, ma quanto è vecchio il suo ultimo template andato a buon fine. Un processo in esecuzione, connesso e sincronizzato può comunque aver smesso di fornire lavoro, e questo bug è stato un modo in cui ciò poteva avvenire in silenzio. La versione della build rientra nello stesso controllo, perché un nodo aggiornato sui template oggi può essere un nodo fuori supporto domani.

Anche le fonti di template di backup richiedono la stessa domanda. Un nodo di failover sulla stessa release e con la stessa politica di mempool avrebbe incontrato la stessa riorganizzazione e lo stesso blocco; due processi in esecuzione non sono due fonti indipendenti di lavoro. Solo un nodo su una build diversa e corretta avrebbe mantenuto l'operazione in mining, e solo un operatore che l'avesse testato sotto una riorganizzazione simulata lo avrebbe saputo in anticipo.