Bitcoin Core corregge i primi bug scovati dall’IA: un peer poteva mandare in crash i nodi Windows e Mac

Mercoledì 28 ottobre 2026 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 pubblicato tre avvisi di sicurezza, i primi diffusi con la regola dei bug «facilmente individuabili» (easily discoverable) che il team aveva aggiunto alla propria politica di sicurezza sei giorni prima. Tutti e tre i difetti sono stati trovati da Project Loupe, una scansione automatica delle vulnerabilità basata su un modello linguistico e gestita da Spiral, la divisione open source di Block dedicata a Bitcoin. Le correzioni arrivano in quattro versioni insieme: 29.5, 30.4, 31.2 e 32.1.

La più seria tra le tre vulnerabilità di Bitcoin Core, classificata come Media, permette a un peer malevolo di esaurire la memoria di un nodo che gira su Windows, macOS o BSD fino a farlo andare in crash. I nodi Linux non sono toccati da questo bug. Secondo l’avviso pubblicato su bitcoincore.org, un peer del genere può mandare in crash «in modo banale» qualsiasi nodo Windows, macOS o BSD a cui è collegato.

Nessun bitcoin è a rischio. I difetti possono fermare un nodo, ma non permettono di spostare né di rubare i fondi di nessuno, e né gli avvisi né le testate che li hanno raccontati, tra cui CoinDesk e Journal du Coin, riportano finora alcuno sfruttamento. Devono muoversi solo chi gestisce un nodo: appassionati, aziende e servizi che custodiscono una propria copia della blockchain. Chi tiene i bitcoin su un exchange o in un’app wallet non deve fare nulla.

La regola, approvata il 22 ottobre, è spiegata nel nostro articolo su Bitcoin Core che abbandona l’embargo di un anno per i bug trovabili con l’IA. La regola è questa: quando un bug è ritenuto facile da scovare, per esempio interrogando un modello linguistico, la correzione viene portata su tutte le versioni ancora mantenute e l’avviso esce insieme alle release, senza il consueto periodo di attesa. Questa settimana è la prima volta che viene applicata.

Dati urgenti TCP: la vulnerabilità di Bitcoin Core che manda in crash i nodi Windows, macOS e BSD

Il bug principale si trova nel codice che legge i dati dei peer. Bitcoin Core sorveglia le connessioni di rete con una funzione chiamata poll() su Linux e con una più vecchia, select(), sugli altri sistemi. Era colpito solo il percorso select(), ed è per questo che le macchine Linux restano al riparo.

Quando un peer manda dati più in fretta di quanto il nodo riesca a elaborarli, Bitcoin Core sospende la lettura da quel peer. È una forma di contropressione (backpressure), e ogni peer ha un limite alla quantità di dati che possono restare in coda. Il difetto: sul percorso select() il nodo continuava a tenere d’occhio i socket sospesi per le «condizioni eccezionali». Un peer poteva provocarne una inviando dati urgenti TCP, detti anche dati fuori banda (out-of-band), una funzione poco usata del protocollo di trasporto di internet. Gestire quell’evento faceva leggere comunque il nodo, e i dati letti così finivano in coda senza alcun limite.

Ripetendo il trucco la coda cresce finché il computer resta senza memoria. Bitcoin Core classifica il bug come Medio e lo segnala come «facilmente individuabile». L’avviso non indica un intervallo esplicito di versioni colpite e, come gli altri due, non riporta alcun identificativo CVE.

Loupe ha segnalato il problema il 23 ottobre. Gregory Sanders, collaboratore di Bitcoin Core, lo ha verificato e ha avvisato lo stesso giorno il team di sicurezza del progetto. Antoine Poinsot ha scritto la correzione, la pull request #36665, aperta, approvata e portata sulle versioni mantenute il 26 ottobre. Le release 31.2 e 32.1 sono arrivate il 27 ottobre, la 29.5 e la 30.4 il 28 ottobre, insieme all’avviso pubblico.

Altri due bug più lenti: la memoria che cresce con i peer in pausa e un file di undo che si riavvolge oltre i 4 GiB

Una coda che cresce di megabyte ogni ora

Il secondo bug di gravità Media, descritto in un avviso a parte sui peer pre-BIP31 in pausa, porta anch’esso all’esaurimento della memoria, ma molto più lentamente. Quando un peer legge troppo piano, Bitcoin Core lo segna come in pausa per l’invio, eppure continua ad accodare alcuni annunci nella sua coda in uscita, soprattutto i frequenti annunci di nuove transazioni. Di norma un peer che non risponde a un ping entro 20 minuti viene disconnesso. Ma un peer che dichiara di non supportare il BIP 31, la modifica del protocollo che ha inserito un nonce casuale nei ping e ha aggiunto la risposta «pong» corrispondente, non viene scollegato se non risponde. Un peer malevolo può quindi presentarsi come vecchio, leggere lentamente di proposito e lasciar gonfiare la coda.

L’avviso quantifica il fenomeno: «Memory usage could grow at a rate of up to 2MB per hour per inbound peer, and 5MB per hour per outbound peer», cioè fino a 2 MB all’ora per ogni peer in entrata e 5 MB all’ora per ogni peer in uscita. I nodi avviati con l’opzione -blocksonly, che non inoltrano le transazioni, sono molto meno esposti, perché gli annunci di transazioni costituiscono la parte più grossa della coda.

Loupe ha segnalato questo difetto a Sanders il 15 settembre, e lui ha avvisato il team di sicurezza lo stesso giorno. Il 21 settembre uno sviluppatore noto come L0rinc lo ha trovato in modo indipendente e lo ha comunicato in privato a Sanders, scoprendo che era già stato segnalato. La correzione, la pull request #36667, è stata approvata e portata sulle versioni mantenute il 26 ottobre.

File di undo, riorganizzazioni e un contatore a 32 bit

Il terzo bug, di gravità Bassa, riguarda l’archiviazione. Un nodo conserva i «dati di undo» in file chiamati rev*.dat: le informazioni che gli servono per annullare un blocco quando la catena si riorganizza e quel blocco viene sostituito. Questi file non avevano un limite di dimensione, e le posizioni al loro interno erano memorizzate come numeri a 32 bit.

Secondo l’avviso sul file di undo, un miner poteva pubblicare blocchi validi con abbastanza dati di undo da spingere un singolo file oltre i 4 GiB. Il contatore di posizione si riavvolge e i dati nuovi sovrascrivono quelli vecchi. Se una riorganizzazione successiva scollega il blocco interessato, il nodo si spegne, e riavviarlo non serve: per recuperare occorre un -reindex con una versione corretta. Su Windows e sui sistemi a 32 bit il limite è di 2 GiB, il nodo non riesce a scrivere i dati di undo oltre quella soglia e si spegne a ogni riavvio. Quella variante richiede circa la metà dei dati e nessuna riorganizzazione.

L’avviso definisce impraticabile lo sfruttamento sui sistemi a 64 bit. Un attaccante dovrebbe minare diverse migliaia di blocchi di transazioni non standard, all’incirca un mese della produzione di blocchi dell’intera rete. Circa 18 dei suoi blocchi dovrebbero poi finire proprio in fondo a un file di blocchi sui nodi presi di mira, e dovrebbe vincere una riorganizzazione di due blocchi. La disposizione dei file di blocchi cambia da nodo a nodo, quindi non esiste un posizionamento valido ovunque. La pagina cita anche un percorso teorico per corrompere l’insieme degli output non spesi del nodo (l’UTXO set), che richiederebbe un controllo ancora maggiore sui file.

Loupe ha segnalato per primo questo bug, l’8 luglio. L0rinc lo ha ritrovato in modo indipendente il 21 agosto e Andrew Dorman il 23 ottobre. La correzione di Poinsot, la pull request #36669, è stata approvata il 26 ottobre con un backport per ogni linea mantenuta: #36658 per la 32.x, #36661 per la 31.x, #36664 per la 30.x e #36666 per la 29.x. Le posizioni nei file di blocchi e di undo sono ora memorizzate come numeri a 64 bit, e le build per Windows usano il posizionamento dei file a 64 bit. Il formato su disco non cambia.

Dalla segnalazione all’avviso pubblico in cinque giorni

Il primo bug è la prova più netta della nuova regola: dalla segnalazione automatica all’avviso pubblico sono passati cinque giorni. La tabella riassume le tre cronologie così come le riportano gli avvisi.

Con il vecchio regime un bug di gravità Media o Alta poteva restare sotto embargo fino a un anno dopo la correzione. Il caso recente più noto è CVE-2024-52911, un crash remoto ad alta gravità nell’interprete degli script: corretto nella versione 29.0 ad aprile 2025, è stato reso pubblico solo a maggio 2026. A ottobre 2025 quattro avvisi di gravità Bassa corretti nella 30.0 sono usciti con i numeri CVE, secondo la stessa procedura precedente. L’argomento di Poinsot a favore del cambiamento, nella sua email alla lista bitcoin-dev, era brusco: «The embargo period achieves little but it delays the availability of a fixed release», ossia l’embargo serve a poco e ritarda la disponibilità di una versione corretta.

Le due segnalazioni più vecchie sollevano una domanda a cui gli avvisi non rispondono. Loupe ha segnalato il bug dell’undo a luglio e la crescita lenta della memoria a settembre, ma le due correzioni sono arrivate lo stesso giorno di quella del bug dei cinque giorni, il 26 ottobre. Le pagine riportano le date, non il motivo dello scarto.

Chi ha trovato i bug: Project Loupe di Spiral

Spiral ha lanciato Loupe il 12 maggio 2026, presentato da Elias Rohrer, Jordan Mecom e Thomas Kilbride. È offerto gratuitamente come «scanning-as-a-service» ai progetti Bitcoin open source. I primi test hanno riguardato Bitcoin Core, BDK, LDK, rust-bitcoin, Cashu, Blockstream Jade, bitcoinj e la Stratum Reference Implementation. I progetti portano il proprio accesso a un modello, mentre Spiral e Block pagano le scansioni che eseguono in prima persona. Spiral descrive lo strumento come indipendente dal modello e non dice quale modello di IA o quale fornitore utilizzi.

Spiral afferma che Loupe «will only report vulnerabilities backed by a demonstrable test case», cioè segnalerà solo vulnerabilità accompagnate da un caso di test dimostrabile. In questo lotto un essere umano ha controllato ogni scoperta prima che arrivasse al team di sicurezza: Sanders ha verificato tutte e tre, secondo gli avvisi e secondo la copertura di CoinDesk e Journal du Coin. I riconoscimenti citano Rohrer per Loupe. L’obiettivo dichiarato di Spiral a lungo termine è passare la scansione ai manutentori di ciascun progetto.

Le riscoperte indipendenti contano quanto la scansione. Due dei tre bug sono stati ritrovati da persone, L0rinc due volte e Dorman una, ed è proprio il caso per cui è stata scritta l’etichetta «facilmente individuabile»: bug che altri, o altre scansioni, hanno buone probabilità di scovare per conto proprio mentre un embargo è in corso.

Questi avvisi si inseriscono in una serie più ampia di ricerche di bug assistite dall’IA nel software Bitcoin a partire da agosto. Non c’entrano con i due difetti di bitcoinjs-lib segnalati questa settimana, che riguardano una libreria JavaScript e un software diverso da Bitcoin Core: vedi il nostro articolo sui bug delle commissioni in bitcoinjs-lib.

Cosa devono fare ora i gestori di nodi Windows, macOS e BSD

I consigli degli avvisi e dell’annuncio della release 32.1 sono brevi. Valgono per chiunque usi Bitcoin Core, con la massima urgenza sulle macchine non Linux.

• I nodi Windows, macOS e BSD devono passare alla versione corretta per la propria linea: 29.5, 30.4, 31.2 o 32.1.
• I nodi Linux non sono esposti al bug dei dati urgenti TCP, ma gli altri due avvisi valgono su ogni piattaforma, quindi l’aggiornamento resta il rimedio.
• Per aggiornare, chiudere completamente la vecchia versione e installare la nuova sopra, come descrive l’annuncio della 32.1.
• Un nodo già fermato dal bug del file di undo non si riprende con un riavvio: va eseguito con -reindex su una versione corretta.
• Scaricare solo da bitcoincore.org e verificare le firme della release prima di installare.

Quale versione scegliere e perché la 32.0 è saltata

La versione 32.0 è stata etichettata ma, secondo l’annuncio della 32.1 pubblicato da fanquake sul forum degli sviluppatori, «never fully announced or released» (mai annunciata né rilasciata davvero) per problemi dell’ultimo minuto, quindi per quella linea la release da usare è la 32.1. Quest’ultima corregge anche un problema separato del wallet: sui sistemi non Windows, un chiamante RPC autenticato autorizzato a creare wallet poteva eseguire comandi quando era impostata l’opzione -walletnotify; ora i nomi dei wallet vengono trattati alla lettera. L’annuncio indica come piattaforme minime il kernel Linux 3.17, macOS 14 e Windows 10 (versione 1903), e dice che la prossima versione maggiore prevede di abbandonare le build realizzate con il compilatore Microsoft MSVC.

Chi usa la 29.x ha ricevuto una versione corretta questa settimana. Per quanto tempo quella linea continuerà a ricevere correzioni è un’altra questione: l’annuncio della 32.1 e la pagina del ciclo di vita del progetto non la formulano allo stesso modo, e questo articolo non si pronuncia.

Ancora esposti dopo la correzione: macchine a 32 bit, unità FAT32 e nodi a fine vita

L’aggiornamento non chiude tutto. Il bug del file di undo resta sfruttabile, con gravità Bassa, sui sistemi a 32 bit e sui nodi che salvano i blocchi su un’unità FAT32, un file system che limita a 4 GiB la dimensione di ogni singolo file. L’avviso cita entrambi i casi. Per il bug della crescita lenta della memoria, -blocksonly riduce l’esposizione.

Il vuoto più ampio riguarda il software vecchio. Solo le linee mantenute ricevono correzioni portate sulle versioni precedenti, e una larga quota della rete pubblica non ne usa una. In una scansione dell’Istituto di Tecnologia di Karlsruhe (KIT) del 18 ottobre, su 9.691 peer raggiungibili IPv4 e IPv6, Coindaro ha contato 8.418 user agent Bitcoin Core semplici, suddivisi come segue (dettagli nel nostro conteggio dei nodi Bitcoin Core su versioni a fine vita).

Per i 3.742 nodi su 28.x o precedenti non esiste alcuna patch. Su Windows, macOS o BSD l’unica protezione dal bug TCP è passare a una versione mantenuta, oppure a un host Linux. Il campione esclude i nodi solo Tor, quelli che non accettano connessioni in entrata e l’infrastruttura privata delle aziende, e le versioni sono dichiarate dai nodi stessi.

Due dati non si conoscono, e Coindaro non li stima. Nessuna fonte indica la quota di nodi che girano su Windows, macOS o BSD: i tracker dei nodi registrano gli user agent, non i sistemi operativi. E la quota già passata alle versioni corrette è vicina a zero per definizione, dato che hanno uno o due giorni di vita. L’istantanea di btcnodes.io recuperata il 29 ottobre contava 18.092 nodi validati, ma non siamo riusciti a ricavarne una suddivisione per versione.

Perché il crash di un nodo non è un furto

Un nodo Bitcoin controlla ogni blocco e ogni transazione in base alle regole e li inoltra ai propri peer. Se va in crash, smette di farlo finché qualcuno non lo riavvia, come ha ricordato Journal du Coin; i bitcoin registrati sulla blockchain non si muovono. Il rischio per un’azienda è il fermo: un processore di pagamenti o un exchange il cui nodo cade non vede le nuove transazioni finché non è tornato in funzione. La nostra guida su dove avvengono davvero gli hack crypto spiega perché gli attacchi al software attorno a una blockchain sono diversi da quelli alla catena stessa.

Le etichette di gravità seguono la scala propria di Bitcoin Core. Il bug TCP è Medio anche se il crash è facile da provocare; l’avviso non spiega il ragionamento dietro la classificazione, e nessuna delle tre pagine collega i bug a una perdita di fondi.

Prossima data: altri tre avvisi attesi intorno all’11 novembre

Il flusso non è finito. L’annuncio della 32.1 dice che la divulgazione delle altre correzioni segue la politica del progetto, e che tre problemi di gravità Media o Alta corretti nella versione 30.0 saranno resi noti «in two weeks», fra due settimane, che CoinDesk interpreta come intorno all’11 novembre. Rientrano nelle regole ordinarie dell’embargo, non nella corsia veloce.

Restano aperti diversi punti: gli identificativi CVE dei tre avvisi di questa settimana (nessuno compare finora nelle pagine, mentre gli avvisi precedenti dello stesso indice ne hanno uno), un intervallo esplicito delle versioni colpite e la quota di nodi che si aggiornerà.