blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il progetto Bitcoin Core ha reso note martedì 10 novembre 2026 tre vulnerabilità di sicurezza, tutte corrette da più di un anno. La più grave, CVE-2025-62861, è classificata come High: dopo una riorganizzazione della catena poteva lasciare un nodo di mining incapace di costruire i template di blocco fino al riavvio manuale. Una seconda, CVE-2025-62860, dava lo stato di fiducia alle connessioni Tor in ingresso sui nodi che usavano un’impostazione di whitelist non predefinita, e secondo l’avviso migliaia di nodi mainnet raggiungibili si trovavano in quella situazione. La terza, CVE-2025-62859, permetteva a un peer ostile di bloccare l’elaborazione dei blocchi. Entrambe sono classificate come Medium.
Le correzioni sono arrivate con Bitcoin Core 30.0 il 10 ottobre 2025, poi con la 29.2 il 14 ottobre e con la 28.3 (per due bug su tre) pochi giorni dopo. Qualsiasi nodo con la 29.2, la 30.0 o una versione più recente le ha già. Gli avvisi su bitcoincore.org non parlano di sfruttamento e Decrypt non ne ha riportati. Nessuno dei tre bug può spostare o rubare monete: nel peggiore dei casi impediscono a un nodo di svolgere il proprio lavoro per un po’.
Chi tiene i bitcoin su un exchange o in un wallet sul telefono non deve fare nulla. Il pubblico di questi avvisi è più ristretto: miner e mining pool, aziende che gestiscono nodi propri e i tanti appassionati che tengono in casa un nodo plug and play, dove il bug di Tor ha fatto più danni.
Le note di rilascio di Bitcoin Core 32.1, pubblicate il 27 ottobre, annunciavano che tre problemi Medium e High corretti nella 30.0 sarebbero stati divulgati due settimane dopo, come aveva già segnalato il nostro articolo sui primi bug di Bitcoin Core scoperti dall’intelligenza artificiale. Questo lotto è distinto da quei bug di ottobre, trovati da una scansione automatica e diventati pubblici subito grazie alla corsia veloce riservata ai difetti facili da scoprire. Questi tre sono stati segnalati da persone tra aprile e settembre 2025 e sono rimasti sotto il normale embargo.
Tre vulnerabilità di Bitcoin Core, una sola data di divulgazione
I tre avvisi sono usciti insieme perché condividono l’ultima linea vulnerabile, la 29.x, arrivata a fine vita il 27 ottobre 2026. Ecco il quadro di ciascuno.
| CVE | Che cosa provoca | Gravità | Versioni interessate | Corretta in | Segnalata da (data) |
|---|---|---|---|---|---|
| CVE-2025-62861 | Blocca la creazione dei template di blocco dopo una riorganizzazione | High | da 28.0 a 28.2, da 29.0 a 29.1 | 28.3, 29.2, 30.0 | Niklas Goegge (26 set 2025) |
| CVE-2025-62860 | Assegna ai peer Tor in ingresso i permessi della whitelist | Medium | Prima di 28.3, 29.2 e 30.0, con -whitelist attivo | 28.3, 29.2, 30.0 | Martin Zumsande e Antoine Poinsot (12 set 2025) |
| CVE-2025-62859 | Blocca l’elaborazione dei blocchi tramite malleazione dei witness | Medium | Prima di 29.2 e 30.0 | 29.2, 30.0 | Eugene Siegel (28 apr 2025) |
Solo CVE-2025-62861 porta l’etichetta High. Una differenza tra le pagine: l’avviso su CVE-2025-62861 data la versione 28.3 al 17 ottobre 2025, quello su CVE-2025-62860 al 20 ottobre.
Il bug ad alta gravità: una riorganizzazione poteva congelare i template di blocco di un miner
CVE-2025-62861 si trova nella mempool, la sala d’attesa in cui un nodo tiene le transazioni non confermate, e riguarda un tipo di transazione più recente. Le transazioni TRUC, sigla di Topologically Restricted Until Confirmation definita nel BIP 431, sono transazioni di versione 3 con limiti stretti sulla loro famiglia non confermata: un genitore TRUC può avere un solo figlio non confermato. La versione 28.0 ha introdotto la «sibling eviction», che permette a un nuovo figlio che paga commissioni sufficienti di sostituire quello esistente.
Questi limiti sono policy della mempool, non regole di consenso. Un blocco valido può contenere famiglie di transazioni che la mempool di un nodo rifiuterebbe. La cosa conta durante una riorganizzazione, quando il nodo abbandona l’ultimo blocco o i due ultimi della propria catena a favore di un ramo più lungo e rimette nella mempool le transazioni dei blocchi scartati. Lo fa con un flag, bypass_limits, pensato proprio per saltare i controlli di policy in questo caso.
Il codice della sibling eviction ignorava il flag. Durante una riorganizzazione poteva espellere una transazione in corso di ripristino lasciando nella mempool i suoi discendenti. Quei discendenti spendevano così output che non esistevano più da nessuna parte.
L’avviso riguarda gli effetti sui miner. Quando il nodo assembla un template di blocco, cioè l’elenco di transazioni che un pool consegna alle proprie macchine, ne verifica la validità. Con i discendenti orfani dentro, la verifica falliva e il nodo non poteva produrre blocchi finché non veniva riavviato, perché il riavvio ricarica una mempool coerente. Le riorganizzazioni di un solo blocco capitano su bitcoin, ma i blocchi riorganizzati dovevano anche contenere le transazioni TRUC giuste.
Niklas Goegge ha segnalato il problema alla mailing list di sicurezza di Bitcoin Core il 26 settembre 2025. Greg Sanders ha aperto la correzione, la pull request #33504, tre giorni dopo; fa rispettare bypass_limits ai controlli TRUC, è stata integrata il 2 ottobre e portata sui rami 29.x, 30.x e 28.x tra il 3 e il 7 ottobre. Erano interessate solo le versioni da 28.0 a 28.2 e da 29.0 a 29.1, perché la sibling eviction non esisteva prima della 28.0.
Un trucco con i compact block che poteva bloccare un nodo
CVE-2025-62859 colpisce il relay dei compact block, il metodo con cui i nodi si passano rapidamente i nuovi blocchi. Invece del blocco intero, un peer manda un breve riassunto e il nodo ricevente ricostruisce il blocco dalle transazioni che ha già nella mempool. Un nodo sceglie fino a tre peer come relay «ad alta banda» che gli spingono i compact block senza che li richieda.
Nelle versioni interessate, il nodo cancellava lo stato di download di un compact block subito dopo averlo ricostruito, ma prima di controllare se i dati witness del blocco fossero stati manomessi (malleati). Se il controllo falliva, il nodo chiedeva lo stesso blocco intero allo stesso peer, con un timeout di 10 minuti. Un peer malevolo che annunciasse per primo un blocco poteva così bloccare l’elaborazione dei blocchi della vittima fino a dieci minuti. Secondo l’avviso, l’attaccante poteva ripetere la manovra all’infinito se controllava tutti e tre i peer ad alta banda della vittima, o se la vittima funzionava in modalità -blocksonly.
Eugene Siegel ha segnalato il bug il 28 aprile 2025. Gregory Sanders ha aperto la correzione, la pull request #32646, il 30 maggio; è stata integrata il 30 giugno e portata sulla linea 29 il 12 settembre. L’avviso elenca correzioni solo nella 29.2 e nella 30.0 e non cita alcuna versione 28.x corretta: la lettura prudente è che la 28.x e le linee più vecchie restino esposte a questo bug.
Il bug della whitelist di Tor dava lo stato di fiducia a sconosciuti su migliaia di nodi
CVE-2025-62860 è quello che più probabilmente interessa chi gestisce un nodo a casa. Bitcoin Core ha un’opzione, -whitelist, che concede permessi speciali ai peer che si collegano da determinati indirizzi IP. I peer in whitelist sono trattati come fidati: il nodo toglie per loro alcuni limiti anti-DoS e alcune protezioni pensate per evitare che trapelino informazioni a peer che potrebbero usarle per spiare le transazioni. L’opzione è disattivata per impostazione predefinita ed è pensata per macchine controllate dall’operatore.
Il problema sta in come appaiono le connessioni Tor dall’interno. Un nodo raggiungibile come servizio nascosto Tor riceve ogni connessione Tor in ingresso dal demone Tor locale, quindi sembrano tutte provenire dallo stesso indirizzo, di solito sulla stessa macchina o rete. Se la whitelist copriva quell’indirizzo, ogni sconosciuto arrivato via Tor ereditava lo stato di fiducia.
Secondo l’avviso, fornitori molto diffusi distribuivano Bitcoin Core insieme a un demone Tor e impostavano -whitelist sull’intervallo dell’indirizzo di quel demone, e anche il software client eseguito accanto a Tor richiedeva spesso l’opzione. È così che migliaia di nodi mainnet raggiungibili hanno messo in whitelist tutte le connessioni Tor in ingresso. L’avviso non cita nessun fornitore, quindi chi usa nodi pacchettizzati che includono Tor farebbe bene a controllare invece di dare la cosa per scontata.
Martin Zumsande e Antoine Poinsot hanno segnalato il problema il 12 settembre 2025. La correzione, la pull request #33395, aperta il 15 settembre, è stata integrata e portata sulle versioni precedenti il 17 settembre; nelle versioni corrette le connessioni in ingresso ricevute su un bind onion non vengono mai messe in whitelist, qualunque sia l’impostazione. Lo stesso giorno Poinsot ha avvisato Luke Dashjr, manutentore di Bitcoin Knots, un client distinto derivato da Bitcoin Core, e il 19 settembre ha avvisato diversi fornitori di software interessati. Le versioni corrette sono arrivate a ottobre 2025.
Quanti nodi riportano ancora versioni interessate
I conteggi di rete danno un’idea di quanto si siano diffuse le correzioni, con dei limiti. Nello snapshot di Bitnodes dell’11 novembre 2026 alle 17:01 UTC (altezza di blocco 975.450), Bitnodes elencava 20.111 nodi raggiungibili. Le versioni provengono dagli user agent che i nodi dichiarano di sé, che si possono modificare o falsificare, e i nodi che non accettano connessioni in ingresso non sono contati affatto. Secondo il conteggio di Coindaro su quel file, 18.048 dei 20.111 annunciavano uno user agent Bitcoin Core semplice, 2.001 uno Knots e 62 altro.
| User agent Bitcoin Core nello snapshot | Nodi | Quota degli agent Core |
|---|---|---|
| Negli intervalli di CVE-2025-62861 (da 28.0 a 28.2, da 29.0 a 29.1) | 1.850 | circa 10,3% |
| Sotto la 29.2 (CVE-2025-62859, limite superiore) | 3.913 | circa 21,7% |
| Sotto le linee corrette di CVE-2025-62860 | 3.861 | circa 21,4% |
| Versione più diffusa, 32.1.0 | 4.567 | circa 25,3% |
Queste quote sovrastimano l’esposizione reale. Il bug High colpisce solo i nodi che costruiscono template di blocco, e quanti nodi di mining usino ancora una versione interessata non si può vedere dall’esterno: l’infrastruttura dei pool è raramente raggiungibile. Il bug di Tor toccava solo i nodi con -whitelist impostato, una quota che nessun crawler misura. La cifra di 1.850 è dominata da 28.1.0 (578 agent semplici e altri 311 di una build FutureBit), 29.0.0 (463), 28.0.0 (231) e 29.1.0 (160).
Knots, con 2.001 nodi raggiungibili e per lo più sulla release 29.3, è un client diverso, e gli avvisi di Core non dicono nulla sulla sua situazione. Il problema più ampio dei nodi che usano linee non più mantenute è stato trattato nel nostro conteggio dei nodi Bitcoin Core su versioni a fine vita, che ha trovato circa il 44% degli agent Core, in una scansione del 18 ottobre, fuori dalle linee supportate.
Che cosa devono controllare ora gli operatori di nodi
Le linee supportate oggi sono 30.x, 31.x e 32.x. Le loro ultime release, la 32.1 (27 ottobre) e la 30.4 e la 31.2 (28 ottobre), contengono anche le correzioni degli avvisi di ottobre. Che cosa fare:
- Controllare la versione che il nodo dichiara (bitcoin-cli getnetworkinfo la mostra, e la maggior parte delle dashboard dei nodi la visualizza). Tutto ciò che è più vecchio della 30.0 sta su una linea che non riceve più correzioni.
- Passare alla 30.4, alla 31.2 o alla 32.1, scaricata da bitcoincore.org, e verificare le firme prima di installare.
- Se si usa un nodo pacchettizzato con Tor, aggiornare il pacchetto e guardare il bitcoin.conf che genera: un intervallo -whitelist che includa l’indirizzo del demone Tor non dovrebbe esserci nelle build più vecchie.
- Pool di mining e miner solitari il cui nodo ha smesso di produrre template dopo una riorganizzazione su una versione interessata dovrebbero riavviarlo, poi aggiornare.
Per chi configura un nodo per la prima volta, la nostra guida passo passo per far girare un nodo Bitcoin spiega download, verifica delle firme e aggiornamenti.
Perché gli avvisi hanno aspettato 13 mesi
Secondo la politica di divulgazione del progetto, a ogni bug viene assegnata una gravità. I problemi di gravità Low vengono divulgati due settimane dopo il rilascio della correzione. Quelli Medium e High restano riservati fino a due settimane dopo il fine vita dell’ultima linea di release che contiene il bug, circa un anno dopo la prima uscita della versione maggiore che lo corregge. I problemi Critical avrebbero con ogni probabilità una procedura ad hoc. Un intervallo di 13 mesi non è insolito: CVE-2024-52911, un bug di crash ad alta gravità corretto nella 29.0 ad aprile 2025, è stato divulgato il 5 maggio 2026.
Il compromesso si vede in questo lotto. La correzione del bug di Tor era codice pubblico da settembre 2025, leggibile da chiunque guardasse la pull request, mentre la spiegazione di ciò che chiudeva è rimasta riservata fino a questa settimana. Gli operatori che aggiornano solo quando compare un avviso sono stati coperti dal ritardo, ma senza sapere il perché. La modifica di ottobre, che pubblica subito i bug facili da trovare insieme alle correzioni, ha spostato una parte del processo nella direzione opposta.
Il prossimo lotto di questo tipo dipende dalla linea 30.x, ora la più vecchia tra quelle mantenute. La pagina del ciclo di vita del progetto ne colloca il fine vita dopo il rilascio della 33.0, e qualsiasi bug Medium o High che contenga ancora verrebbe divulgato due settimane dopo.