Aggiornato al 31 ottobre 2026.
Bitcoin Core ha pubblicato il 28 ottobre tre advisory su vulnerabilità che possono compromettere la disponibilità dei nodi. Le correzioni sono incluse nelle versioni 29.5, 30.4, 31.2 e 32.1, ma non tutte le piattaforme sono coinvolte allo stesso modo e alcuni limiti restano sui sistemi a 32 bit e su FAT32.
Il caso più immediato riguarda Windows, macOS e BSD: un peer malevolo collegato può provocare l’esaurimento della memoria attraverso dati TCP urgenti. Linux non è interessato da questo specifico bug. Non significa però che Linux sia escluso dagli altri due advisory o che qualsiasi consumo elevato di RAM dimostri un attacco.
Bitcoin Core: quali versioni contengono le correzioni
Gli advisory identificano gli stessi quattro rilasci correttivi. La disponibilità di Bitcoin Core 32.1 è annunciata sul sito ufficiale; per scegliere un aggiornamento occorre leggere anche le note della versione e verificarne la compatibilità con l’installazione concreta.
L’elenco delle versioni corrette non è una raccomandazione a restare indefinitamente su un ramo vecchio. Dimostra dove è stata distribuita questa correzione, non garantisce la manutenzione futura di ogni ramo. Il riferimento temporale di questo articolo è il 31 ottobre: eventuali rilasci successivi vanno valutati sulle fonti del progetto.
| Advisory | Problema | Distinzione importante |
|---|---|---|
| CVE-2026-117350 | Memoria senza limite con dati TCP urgenti | Percorso non Linux; gravità media |
| CVE-2026-117349 | Accumulo lento di annunci per peer pre-BIP31 | Non limitato al bug TCP; gravità media |
| CVE-2026-117346 | Overflow dei file undo | Condizioni estreme; gravità bassa, limiti residui su 32 bit/FAT32 |
Il bug TCP non riguarda Linux
L’advisory TCP descrive un problema nel percorso basato su select(), diverso dal percorso usato su Linux. Una condizione eccezionale del socket permetteva di leggere altri dati anche quando il programma aveva sospeso le letture per contenere la coda.
Il risultato poteva essere una crescita senza limite fino al crash del nodo. La classificazione ufficiale è media e il problema richiede un peer connesso: non è la descrizione di un accesso alle chiavi private. La piattaforma del nodo conta più di quella del telefono con cui il proprietario consulta il saldo.
La seconda vulnerabilità fa crescere la coda lentamente
L’advisory sui peer pre-BIP31 riguarda invece gli annunci accodati verso un interlocutore che non legge abbastanza velocemente. Un peer poteva dichiarare di non supportare i ping con nonce previsti da BIP31 ed evitare il normale meccanismo di disconnessione legato alla mancata risposta.
Il progetto indica una crescita fino a 2 MB all’ora per peer in ingresso e 5 MB all’ora per peer in uscita. Sono limiti descritti per questo scenario, non una previsione del consumo di ogni nodo. La modalità -blocksonly riduce sensibilmente l’esposizione perché molti messaggi accodati sono annunci di transazioni, ma non viene presentata qui come sostituto dell’aggiornamento.
File undo: perché 32 bit e FAT32 restano un limite
I file undo servono a disconnettere blocchi durante una riorganizzazione della catena. L’advisory sull’overflow descrive un caso estremo nel quale dati molto grandi possono corrompere le informazioni necessarie e fermare il nodo. Il progetto lo classifica a gravità bassa e ne considera impraticabile lo sfruttamento su sistemi a 64 bit nelle condizioni descritte.
La correzione usa posizioni a 64 bit, ma l’avviso mantiene esplicitamente l’eccezione per sistemi a 32 bit e cartelle dei blocchi su FAT32. Avere installato un numero di versione corretto non basta quindi a ignorare architettura e filesystem. Anche Windows ha ricevuto una correzione delle chiamate di posizionamento: non va confuso con l’eccezione generale dei sistemi a 32 bit.
Crash del nodo non significa furto del wallet
Questi avvisi non annunciano l’estrazione automatica di seed phrase o chiavi private. Il ruolo di un nodo e quello della custodia sono distinti, come chiarisce la nostra guida ai wallet custodial e non custodial. L’interruzione di un servizio resta importante, ma non dimostra da sola che un saldo sia stato rubato.
Nemmeno ogni errore è riconducibile a queste vulnerabilità: max-fee-exceeded, per esempio, riguarda una salvaguardia sulle commissioni. Confondere messaggi diversi porta a interventi inutili o rischiosi. Prima di cambiare configurazione servono versione effettiva, piattaforma e sintomo documentato.
Cosa controllare senza improvvisare un recupero
Gli advisory attribuiscono le scoperte a una scansione con modelli linguistici del Project Loupe e indicano la validazione umana delle segnalazioni prima dell’invio al team. Questo passaggio non dimostra che un modello possa correggere autonomamente qualsiasi software: distingue una segnalazione automatica da un problema verificato e da una patch distribuita.
Per due problemi sono inoltre riportate riscoperte indipendenti. La presenza di strumenti AI nel processo non modifica il controllo che interessa al gestore del nodo: verificare quale codice sta eseguendo e quali condizioni specifiche restano applicabili alla propria macchina.
Per chi gestisce un nodo, i controlli iniziali sono versione realmente in esecuzione, sistema operativo, architettura e filesystem della cartella dei blocchi. Gli aggiornamenti vanno ottenuti dai canali ufficiali, seguendo le verifiche di autenticità del progetto e preservando i backup del wallet. Una nuova release non richiede mai di comunicare la seed a un servizio di assistenza.
L’advisory undo menziona una reindicizzazione con versione corretta per recuperare lo specifico danno descritto. Non è un invito a lanciare -reindex su ogni nodo lento: prima bisogna confermare la diagnosi, proteggere i dati e considerare tempi e risorse. Qui non abbiamo riprodotto gli attacchi né testato installazioni: il punto è leggere correttamente correzioni e limiti pubblicati.
