Bitcoin Core, il software di riferimento per i nodi della rete, ha aggiornato la propria policy di sicurezza sulle vulnerabilità: i bug che si possono scoprire con un semplice prompt a un modello di intelligenza artificiale non seguiranno più l’embargo standard legato alla gravità. Lo ha comunicato lo sviluppatore Antoine Poinsot il 22 ottobre 2026 con una email alla Bitcoin Development Mailing List.
Per queste falle, definite “facili da scoprire”, il progetto promette una correzione su tutte le versioni mantenute e un avviso pubblico in tempi brevi. BitcoinLive24 ha letto l’email, la nuova policy e le regole sul ciclo di vita delle versioni per spiegare cosa cambia per chi gestisce un nodo.
Perché Bitcoin Core cambia la policy di sicurezza: i bug si scoprono più facilmente
Bitcoin Core ha registrato un aumento delle segnalazioni di vulnerabilità facili da (ri)scoprire, che Poinsot attribuisce soprattutto ai modelli linguistici. Nell’email scrive che gli LLM hanno abbassato in modo netto la soglia per trovare certe classi di errori o per individuare correzioni “coperte”, in inglese covert fixes, cioè correzioni che non dichiarano la falla.
Poinsot descrive una tensione tra due obiettivi: la trasparenza, che mette attaccanti e difensori sullo stesso piano, e il tempo concesso agli utenti per aggiornare. Per la natura del progetto e per una cultura dell’aggiornamento lenta, la policy finora favoriva un embargo lungo. Questo significa, scrive, che le correzioni di sicurezza in genere non potevano essere riportate sulle versioni precedenti e arrivavano agli utenti solo con la major release successiva. Per i bug facili da trovare, aggiunge, è lo scambio sbagliato: “l’embargo ottiene poco, ma ritarda la disponibilità di una versione corretta”.
Il quadro generale è quello descritto da Cointelegraph, che il 23 ottobre ha ripreso la notizia: secondo la testata, ad agosto il gruppo volontario Bitcoin Red Team ha segnalato quasi 5.000 potenziali problemi in 390 progetti, anche se in quel momento solo circa un quinto dei casi era stato riprodotto.
La nuova regola per i bug “facili da scoprire”: fix su tutte le versioni mantenute
Durante la valutazione di una segnalazione, i responsabili possono ora classificare la vulnerabilità come “facile da scoprire”. Secondo la pagina ufficiale degli advisory di Bitcoin Core, la definizione riguarda i difetti individuabili con il minimo sforzo, per esempio con un semplice prompt a un LLM; Poinsot precisa che la classificazione non si limita a quel caso.
Per questi bug la pagina prevede una versione di manutenzione con la correzione per ogni versione maggiore mantenuta, pubblicata il prima possibile e accompagnata da un avviso di sicurezza, senza applicare gli embarghi standard legati alla gravità. L’email aggiunge che l’avviso conterrà alcuni dettagli insieme alle release corrette.
Le quattro classi di gravità e le tempistiche di divulgazione restano per gli altri bug
La policy distingue quattro classi di vulnerabilità: critica, alta, media e bassa. Le falle critiche sono quelle che minacciano la sicurezza fondamentale dell’intera rete, come il furto di monete a livello di protocollo, la creazione di coin fuori dal calendario di emissione o le divisioni permanenti della blockchain. Per questa classe la pagina non fissa tempi standard: scrive che richiederebbe con ogni probabilità una procedura ad hoc.
Per tutti gli altri casi vale il calendario basato sulla gravità: secondo la pagina ufficiale, le falle di classe bassa vengono rese pubbliche due settimane dopo il rilascio della major con la correzione, quelle di classe media e alta due settimane dopo la fine vita dell’ultima versione colpita. Tra gli esempi citati dalla policy ci sono CVE-2018-17144 per la classe critica, CVE-2024-35202 per l’alta e CVE-2024-52920 per la bassa.
| Classe di gravità | Quando viene divulgata (policy aggiornata) | Esempio / definizione dalla policy |
|---|---|---|
| Facile da scoprire | Release di manutenzione per ogni versione mantenuta il prima possibile, con avviso | Difetti individuabili con il minimo sforzo (la policy cita un semplice prompt a un LLM) |
| Critica | Nessun tempo standard: procedura ad hoc | CVE-2018-17144 (inflazione dell’offerta di bitcoin) |
| Alta e media | 2 settimane dopo che l’ultima versione colpita va in fine vita (circa un anno dopo la major con la correzione) | CVE-2024-35202 (crash remoto, classe alta) |
| Bassa | 2 settimane dopo il rilascio della major con la correzione | CVE-2024-52920 (CPU al 100% con messaggio GETDATA) |
La pagina spiega inoltre che due settimane prima della divulgazione di una falla sotto embargo viene diffuso un preannuncio, in coincidenza con il rilascio di una nuova major version, con il numero di vulnerabilità corrette e la loro gravità.
Quali versioni di Bitcoin Core ricevono le correzioni: 29.x, 30.x e 31.x
Bitcoin Core mantiene sempre le ultime tre versioni maggiori, come indica la pagina sul ciclo di vita del software. Nella tabella ufficiale la 31.x è uscita il 19 aprile 2026, la 30.x il 10 ottobre 2025 e la 29.x il 14 aprile 2025, mentre la 32.x è indicata come data da definire (TBA). La 28.x è andata in fine vita il 19 aprile 2026.
La stessa pagina avverte che le versioni giunte a fine vita in genere non ricevono correzioni di sicurezza e raccomanda di usare l’ultima release di manutenzione della versione maggiore più recente possibile. Per le falle facili da scoprire, la policy indica proprio le release di manutenzione come canale della correzione. Sulla precedente patch di sicurezza di Bitcoin Core si veda Bitcoin Core 31.1: patch di sicurezza critica; sul prossimo ramo, Bitcoin Core 32.0 e la release candidate 4.
L’IA cambia la sicurezza del software Bitcoin: reazioni e altri casi
Secondo Cointelegraph, Luke de Wolf, conduttore del Bitcoin Infinity Show e autore di “Defending Bitcoin”, ha commentato di aver avuto in passato disaccordi con l’approccio di Poinsot alla sicurezza, ma di considerare questo “un buon aggiornamento”.
Il tema riguarda anche altri progetti dell’ecosistema. Secondo Cointelegraph, ad agosto gli sviluppatori di Core Lightning, il software per i nodi Lightning, hanno invitato gli operatori ad aggiornare o a spegnere i nodi dopo aver ricevuto più segnalazioni di vulnerabilità generate con l’IA, trattenendo i dettagli tecnici per due settimane. Ne abbiamo parlato anche in Core Lightning avverte: attacchi ai nodi non aggiornati.
In pratica, per chi gestisce un nodo la novità sta nel canale: per i bug facili da scoprire la correzione arriverà in una release di manutenzione di ciascuna versione mantenuta, e la pagina sul ciclo di vita raccomanda di usare l’ultima release di manutenzione della versione maggiore più recente possibile. Per seguire gli sviluppi in tempo reale, scarica l’app BitcoinLive24.
Domande frequenti sulla nuova policy di sicurezza di Bitcoin Core
Che cosa significa che una vulnerabilità è “facile da scoprire”?
È un difetto che si può individuare con il minimo sforzo, per esempio con un semplice prompt a un modello linguistico. Secondo la policy di Bitcoin Core, in questi casi viene pubblicata il prima possibile una release di manutenzione con la correzione per ogni versione mantenuta, insieme a un avviso di sicurezza.
I fondi in bitcoin sono a rischio per questa modifica?
Le fonti non segnalano perdite di fondi né una falla attiva: l’email e la pagina ufficiale descrivono solo come cambia la gestione e la divulgazione delle vulnerabilità. Non dicono però che gli utenti siano esenti da rischio. Le falle critiche, che riguardano la sicurezza dell’intera rete, restano escluse dalla policy standard e seguono una procedura ad hoc.
Devo aggiornare il mio nodo Bitcoin Core?
Se usi una versione giunta a fine vita, sì: la pagina sul ciclo di vita indica che in genere non riceve più correzioni di sicurezza. Il consiglio ufficiale è eseguire l’ultima release di manutenzione della versione maggiore più recente che puoi installare.
Perché prima le correzioni arrivavano in genere solo con la major release?
Perché un embargo lungo, spiega Poinsot, in genere impediva di portare il fix sulle versioni già in circolazione. Chi usava una release precedente doveva quindi attendere la major successiva.
