Bitcoin Core ha reso pubbliche il 28 ottobre 2026 tre vulnerabilità trovate da una scansione automatica basata su un modello linguistico (IA), secondo i tre avvisi ufficiali (dati TCP urgenti, peer pre-BIP31, file undo) pubblicati sul sito del progetto. Due riguardano il consumo di memoria dei nodi, la terza i file che servono a gestire le riorganizzazioni della catena. Tutte e tre sono corrette nelle versioni 29.5, 30.4, 31.2 e 32.1; la terza però solo per i sistemi a 64 bit, mentre i nodi a 32 bit e con i blocchi su FAT32 restano esposti.
La notizia è stata ripresa da CoinDesk, che ha titolato sui nodi Bitcoin su Windows e Mac che possono essere mandati in crash. Qui si ricostruisce cosa dicono gli avvisi originali, con gravità, sistemi esposti e versioni corrette.
Bitcoin Core: le tre falle divulgate il 28 ottobre
Il progetto ha classificato tutte e tre le falle come “facilmente individuabili” (easily discoverable). Due hanno gravità media e una bassa, secondo gli avvisi.
| Falla | Gravità | Chi è esposto | Versioni con la correzione |
|---|---|---|---|
| Memoria illimitata via dati TCP urgenti | Media | Nodi su Windows, macOS e BSD (non Linux) | 29.5, 30.4, 31.2, 32.1 |
| Coda in crescita su peer in pausa pre-BIP31 | Media | Nodi collegati a un peer malevolo; molto meno colpiti quelli in -blocksonly | 29.5, 30.4, 31.2, 32.1 |
| Overflow del file undo | Bassa | Tutti i sistemi; su 32 bit e FAT32 resta aperta | 29.5, 30.4, 31.2, 32.1 |
Fonte: avvisi di sicurezza di Bitcoin Core, 28 ottobre 2026.
Dati TCP urgenti: un peer può esaurire la memoria su Windows e macOS
Secondo il primo avviso, un peer malevolo può far esaurire la memoria di un nodo inviando dati TCP “urgenti” (un meccanismo che permette di superare la coda normale dei dati). L’avviso afferma che in pratica un peer connesso può mandare in crash “banalmente” qualsiasi nodo Windows, macOS o BSD.
Il difetto riguarda solo il codice che monitora i socket con la funzione select(), usata fuori da Linux. Su Linux, dove il nodo usa poll(), il problema non c’è. Il meccanismo di protezione, che sospende la lettura quando la coda di un peer è troppo lunga, veniva aggirato dall’evento dei dati urgenti, che innescava comunque una lettura.
Peer pre-BIP31 in pausa: la memoria cresce fino a 5 MB l’ora
Il secondo avviso descrive un attacco lento. Il BIP 31 introduce un ping con codice di verifica, e i nodi disconnettono dopo 20 minuti i peer che non rispondono. Un peer che finge di non supportare il BIP 31 evita la disconnessione e, leggendo i messaggi con ritardo, fa crescere senza limite la coda di annunci del nodo.
La crescita arriva fino a 2 MB l’ora per ogni peer in entrata e 5 MB l’ora per ogni peer in uscita, indica l’avviso. I nodi avviati con -blocksonly sono molto meno colpiti, perché secondo l’avviso gli annunci di transazioni costituiscono la parte più grande dei messaggi in coda.
File undo: gravità bassa e sfruttamento impraticabile su 64 bit
Il terzo avviso è l’unico a gravità bassa, e l’avviso giudica impraticabile sfruttarlo sui sistemi a 64 bit. Un miner può produrre blocchi validi con dati di annullamento (undo) molto più grandi dei blocchi, fino a superare i 4 GiB in un solo file. Oltre quella soglia la posizione a 32 bit si azzera e i dati più recenti sovrascrivono i vecchi.
Se una riorganizzazione della catena ripercorre uno di quei blocchi, il nodo non riesce a leggere i dati e si spegne. Riavviarlo non aiuta: serve un -reindex con una versione corretta. L’avviso stima che l’attaccante dovrebbe minare diverse migliaia di blocchi, circa un mese dell’intera produzione di blocchi della rete, e vincere una riorganizzazione di 2 blocchi.
Su Windows e sui sistemi a 32 bit il quadro cambia: il limite di 2 GiB sul posizionamento nei file fa fallire la scrittura dei dati undo già a metà dello spazio, senza bisogno di riorganizzazione, e il nodo si ferma a ogni riavvio. La correzione salva le posizioni come interi a 64 bit e su Windows usa chiamate di posizionamento a 64 bit: copre quindi i sistemi a 64 bit, Windows compreso. I nodi a 32 bit e quelli con la cartella dei blocchi su FAT32 restano esposti anche dopo l’aggiornamento.
Chi ha trovato le falle e perché conta
Tutte e tre sono state scoperte tramite una scansione con modello linguistico nell’ambito di Project Loupe, il progetto di Elias Rohrer presso Spiral. Ogni segnalazione è stata validata e portata al team di sicurezza da Gregory Sanders. La seconda falla è stata riscoperta in autonomia da L0rinc, che il 21 settembre 2026 l’ha notificata in privato a Sanders avendo come risposta che era già stata segnalata, e la terza è stata segnalata indipendentemente anche da L0rinc e da Andrew Dorman.
Sono bug del tipo a cui si applica la nuova policy di sicurezza di Bitcoin Core sui difetti facili da trovare con l’IA. Per la prima falla, trovata il 23 ottobre, la correzione è stata unita al codice il 26 ottobre e rilasciata il 27 ottobre nelle versioni 31.2 e 32.1, poi il 28 ottobre nelle 29.5 e 30.4.
Cosa fare e cosa aspettarsi
Chi gestisce un nodo dovrebbe passare a una delle versioni corrette: i nodi Linux sono esenti solo dalla prima falla, mentre le altre due riguardano anche loro. BitcoinLive24 ha scritto anche del rilascio di Bitcoin Core 32.1. Chi ha un nodo a 32 bit o dati su FAT32 deve sapere che l’aggiornamento non risolve la terza falla.
Secondo CoinDesk, altre tre vulnerabilità di gravità media e alta, corrette nella 30.0, saranno divulgate tra circa due settimane. Gli avvisi del 28 ottobre non le descrivono.
Scarica l’app BitcoinLive24 per ricevere le novità sulla sicurezza dei nodi Bitcoin.
Domande frequenti sulle falle di Bitcoin Core
Quali versioni di Bitcoin Core contengono le correzioni?
Le versioni 29.5, 30.4, 31.2 e 32.1 contengono le correzioni per tutte e tre le falle, secondo gli avvisi ufficiali. La 31.2 e la 32.1 sono uscite il 27 ottobre, la 29.5 e la 30.4 il 28 ottobre 2026.
Un nodo Linux è a rischio di crash per i dati TCP urgenti?
No: l’avviso precisa che gli utenti Linux non sono interessati, perché il nodo usa poll() invece di select(). Il difetto riguarda Windows, macOS e BSD.
Perché l’aggiornamento non risolve tutto sui sistemi a 32 bit?
Perché le versioni corrette usano ancora chiamate di posizionamento limitate a 2 GiB sui sistemi a 32 bit, e FAT32 limita i file a 4 GiB. Secondo l’avviso sull’overflow undo, questi nodi restano esposti anche dopo l’aggiornamento.
