Nella politica di sicurezza di Bitcoin Core c’è ora una corsia veloce per i bug facili da trovare. Con una modifica approvata giovedì 22 ottobre 2026 per pool di un market maker automatico divergono, rispetto a tenere semplicemente gli stessi token. Diventa definitiva al prelievo.">il software di riferimento con cui si gestisce un nodo Bitcoin, una vulnerabilità che il team classifica come «facilmente individuabile» (easily discoverable) sarà corretta in tutte le versioni mantenute contemporaneamente, e i dettagli finiranno in un avviso di sicurezza pubblicato insieme alle versioni corrette, senza un embargo legato alla gravità. La modifica è passata dalla pull request n. 1281 sul repository del sito del progetto, aperta il 16 ottobre da Antoine Poinsot (darosior su GitHub) e integrata dal manutentore fanquake.
Il criterio è riassunto in una riga nella nuova pagina della politica di sicurezza di Bitcoin Core: vulnerabilità «che possono essere scoperte con uno sforzo minimo, per esempio con un semplice prompt a un LLM». Se un modello linguistico può indicare il bug a un attaccante, tenerlo nascosto per mesi serve a poco.
Si tratta di un cambio di procedura. Non annuncia una vulnerabilità, un exploit o un difetto nella crittografia di Bitcoin, e nessun bitcoin è a rischio. Per chi detiene BTC oggi non cambia nulla. Cambia invece il modo in cui arriveranno le correzioni per chi gestisce un nodo.
Cosa cambia nella politica di sicurezza di Bitcoin Core
Poinsot ha spiegato il ragionamento in un’email alla mailing list bitcoin-dev il 22 ottobre, giorno dell’integrazione. Ha scritto che il progetto riceve sempre più segnalazioni di vulnerabilità facili da trovare o da riscoprire, e ha collegato il fenomeno ai modelli linguistici: rendono molto più economica la ricerca di certe classi di bug e permettono anche di individuare le correzioni «coperte», cioè le patch entrate nel codice senza essere etichettate come interventi di sicurezza. La divulgazione, ha sostenuto, è sempre un compromesso: pubblicare i dettagli aiuta i difensori a tenere il passo degli attaccanti, mentre aspettare dà agli utenti il tempo di aggiornare.
Secondo l’email, finora l’approccio privilegiava un embargo lungo perché molti operatori di nodi aggiornano lentamente. L’effetto collaterale era che le correzioni spesso non potevano essere riportate sulle versioni precedenti e arrivavano solo con il successivo rilascio maggiore. Per i bug che chiunque può trovare, Poinsot ha definito questa scelta «il compromesso sbagliato». La sintesi è netta: «L’embargo serve a poco, ma ritarda la disponibilità di una versione corretta».
Il meccanismo si riassume in poche righe. Durante il triage, il team può segnalare un bug come facilmente individuabile. Per un bug così classificato la correzione viene riportata su tutte le versioni maggiori mantenute, le relative versioni di manutenzione escono il prima possibile e con esse un avviso di sicurezza che riporta alcuni dettagli del problema. L’email indica come caso tipico quello del «semplice prompt a un LLM» e precisa che la categoria non si limita a questo.
I livelli di gravità restano quelli di prima
Per i bug non segnalati come facili, tutto il resto della politica continua ad applicarsi. Le segnalazioni sono ripartite in quattro livelli, ciascuno con il proprio ritardo di divulgazione. La pagina attuale li presenta così.
| Gravità | Cosa comprende (secondo la pagina della politica) | Quando vengono pubblicati i dettagli |
|---|---|---|
| Bassa | Difficile da sfruttare, o impatto minore | 2 settimane dopo il rilascio della versione maggiore che contiene la correzione |
| Media | Degrada in modo percepibile prestazioni o funzioni, spesso richiede impostazioni non predefinite | 2 settimane dopo che l’ultima versione interessata raggiunge la fine del supporto |
| Alta | Impatto significativo su nodi o rete, in genere sfruttabile da remoto con la configurazione predefinita | 2 settimane dopo che l’ultima versione interessata raggiunge la fine del supporto |
| Critica | Minaccia la rete stessa: furto di monete a livello di protocollo, monete create fuori dal calendario di emissione, divisione permanente della catena su tutta la rete | Non prevista dalla politica standard; con ogni probabilità una procedura ad hoc |
| Qualsiasi livello, se segnalato come facilmente individuabile (novità) | Si può trovare con uno sforzo minimo, per esempio con un semplice prompt a un LLM | Insieme alle versioni di manutenzione corrette, il prima possibile, senza embargo legato alla gravità |
Per i bug di gravità media e alta, aspettare che l’ultima versione interessata arrivi a fine supporto significa in pratica circa un anno dopo l’uscita della versione maggiore che contiene la correzione. Un preavviso, con il numero delle vulnerabilità corrette e la loro gravità, arriva due settimane prima della pubblicazione dei dettagli sotto embargo ed è sincronizzato con una nuova versione maggiore. La pagina ricorda anche che alcune segnalazioni possono essere gravi ma non richiedere alcun embargo, e che altre si rivelano non essere vulnerabilità.
La modifica in sé è piccola. Aggiunge due paragrafi alla pagina, sopra le tempistiche esistenti, e cambia una locuzione: il preavviso si applica ora a «una vulnerabilità sotto embargo» e non più a qualsiasi vulnerabilità. Le righe che fissano i ritardi per i livelli basso, medio e alto non sono toccate. Una versione giapponese della pagina è stata aggiornata il 23 ottobre.
Perché gli sviluppatori dicono che la segretezza vale meno quando un’IA trova il bug
Un embargo ha senso quando solo chi ha segnalato il difetto e i manutentori ne sono al corrente. Ne ha molto meno quando chiunque, con un chatbot e il codice sorgente pubblico, può trovare la stessa cosa con poco sforzo. È il cuore dell’argomento portato da Poinsot nella discussione della pull request tra il 16 e il 22 ottobre: correggere in silenzio un bug facile serve a poco, perché «una banale scansione con un LLM» può comunque farlo emergere, e riportare la correzione sui rami più vecchi lo rivelerebbe.
La regola di base, ha detto nel thread, resta quella di non attirare attenzione inutile sulle correzioni di sicurezza, con più margine per derogare. Le correzioni rilasciate così in fretta hanno meno tempo di test nei rami di sviluppo, quindi si aspetta che il team accetti una patch più semplice che lascia intuire il bug, se è più sicura, piuttosto che una mascherata che potrebbe rompere qualcos’altro.
I revisori hanno discusso i dettagli più che l’idea. stickies-v ha chiesto di integrare il testo nella formulazione esistente invece di aggiungerlo in fondo, cosa che Poinsot ha fatto il 22 ottobre. Lo stesso revisore temeva che gli attaccanti possano ormai sorvegliare il repository a basso costo, per cui una pull request pubblica con la correzione potrebbe avvisarne molti giorni o settimane prima che la maggior parte degli utenti ne sappia qualcosa, e ha proposto di divulgare al più tardi nel momento in cui quella pull request viene aperta. sedited dubitava che una divulgazione così anticipata andasse scritta nella politica, preferiva decidere quei casi di volta in volta e ha detto che contrassegnare come correzioni di sicurezza le pull request all’apertura non servirebbe.
ariard ha proposto una sezione separata, «Derogatory Process», un percorso accelerato in cui un avviso potrebbe essere pubblicato o meno insieme alla correzione. Poinsot l’ha definita «una cattiva idea»: un allarme senza dettagli potrebbe spingere gli utenti non coinvolti a un aggiornamento affrettato. Il suo esempio era un bug nella creazione dei template di blocco, per cui i miner dovrebbero aggiornare subito mentre i commercianti possono procedere con più calma. Per i bug abbastanza gravi da avvisare gli utenti prima che esista una correzione, ha indicato il livello Critico, già gestito ad hoc. Quattro revisori, stickies-v, instagibbs, murchandamus e fanquake, hanno approvato il testo finale, e fanquake lo ha integrato.
Sotto il messaggio di Poinsot sulla mailing list non risultavano risposte quando Coindaro lo ha consultato, il 23 ottobre.
Un anno di bug trovati dall’IA nel software bitcoin
La modifica arriva dopo una serie di episodi, nel 2026, in cui strumenti automatici, spesso assistiti dall’IA, hanno portato alla luce difetti più in fretta di quanto i progetti riuscissero a smistarli.
Il 6 agosto un gruppo di volontari che si fa chiamare Bitcoin Red Team ha segnalato 4.962 possibili problemi in 390 progetti nelle prime 29,8 ore circa di lavoro, secondo Cointelegraph. Circa 720 erano valutati come gravi o critici e il 21,4% era già stato riprodotto. I 16 volontari, tra cui l’amministratore delegato di AnchorWatch Rob Hamilton e lo sviluppatore noto come Calle, hanno combinato strumenti di IA e revisione umana. Cointelegraph non ha precisato se tra i progetti analizzati ci fossero anche i repository di Bitcoin Core.
Core Lightning ha dovuto affrontare la questione in prima persona. In agosto il progetto ha dichiarato di lavorare su un gran numero di segnalazioni di vulnerabilità generate dall’IA e ha rilasciato la versione 26.06.7. La 26.06.8 è arrivata il 22 settembre con correzioni per crash innescabili da un mittente, esaurimento della memoria tramite l’interfaccia REST e un bug nella chiusura dei canali che poteva costare fondi a causa di una penalità. Il 2 ottobre il team ha avvertito che i nodi con la 26.06.7 o precedenti erano nel mirino e ha chiesto agli operatori di passare all’ultima versione, ha riferito Cointelegraph; alcuni test sono stati tenuti volutamente riservati.
Anche i portafogli hardware sono entrati nella vicenda. I furti legati a Coldcard iniziati il 30 luglio, ricondotti a un generatore di numeri casuali software debole in alcuni dispositivi, sono ora al centro di una class action proposta contro Coinkite in Ontario. Nessuno di questi casi era un bug in Bitcoin Core.
Quali versioni di Bitcoin Core ricevono le correzioni
La promessa del backport riguarda solo le versioni mantenute. Il progetto mantiene le ultime tre versioni maggiori, secondo la pagina sul ciclo di vita dei rilasci, e le versioni oltre la fine del supporto in genere non ricevono correzioni di sicurezza. Al 23 ottobre 2026 la situazione è questa:
| Versione maggiore | Primo rilascio | Fine del supporto |
|---|---|---|
| 31.x | 19 aprile 2026 | Dopo l’uscita della v34.0 |
| 30.x | 10 ottobre 2025 | Dopo l’uscita della v33.0 |
| 29.x | 14 aprile 2025 | Dopo l’uscita della v32.0 |
| 28.x | 2 ottobre 2024 | Terminato il 19 aprile 2026 |
Il progetto punta a una versione maggiore ogni sei o sette mesi, e la data di rilascio della 32.0 non è stata annunciata; la pagina sul ciclo di vita elenca già la 32.x come supportata fino all’uscita della 35.0. Quando uscirà, la 29.x perderà il supporto e uscirà dalla corsia veloce.
Cosa possono fare ora gli operatori di nodi
Le pagine del progetto indicano i passi pratici. Nessuno è nuovo, ma il cambio di politica li rende più importanti, perché un bug facile potrebbe essere pubblico lo stesso giorno della correzione.
- Usare una versione maggiore mantenuta (31.x, 30.x o 29.x), meglio se l’ultima versione di manutenzione della più recente utilizzabile. I nodi con la 28.x o precedenti sono oltre la fine del supporto e in genere non ricevono correzioni di sicurezza.
- Seguire gli annunci del progetto e la pagina degli avvisi di sicurezza, così che una versione di manutenzione fuori calendario non passi inosservata.
- Scaricare le versioni solo da bitcoincore.org e verificare le firme; il progetto afferma che i suoi binari sono compilati in modo deterministico e firmati.
- Per aggiornare, spegnere completamente il nodo e installare la nuova versione sopra la vecchia, come descrivono le note di rilascio.
- Gli operatori Lightning che usano Core Lightning dovrebbero avere l’ultima versione (26.06.8 o successiva), dopo l’avviso del team del 2 ottobre.
Quanti bug finiranno nella nuova categoria, la politica non lo dice. Ogni bug segnalato comporta una versione di manutenzione per ogni ramo mantenuto, quindi chi aspetta la prossima versione maggiore per aggiornare sarà quello rimasto esposto.
Embargo, backport e versioni di manutenzione in parole semplici
I progetti open source gestiscono di solito i bug di sicurezza con la divulgazione coordinata. Chi ha trovato il difetto lo comunica in privato ai manutentori, la correzione viene preparata e i dettagli restano riservati (l’embargo) finché abbastanza utenti non hanno aggiornato. Più lungo è l’embargo, più nodi sono già protetti quando gli attaccanti scoprono cosa cercare.
Un backport è la stessa correzione applicata ai rami più vecchi ancora supportati, così chi usa la 29.x non deve passare alla 31.x per essere al sicuro. Una versione di manutenzione, come la 31.1, è un piccolo aggiornamento di una versione maggiore esistente. Con la nuova regola, un bug facilmente individuabile produce un insieme di versioni di manutenzione su ogni ramo mantenuto e un avviso che spiega cosa è stato corretto. La nostra guida su dove avvengono davvero gli attacchi alle crypto spiega perché, nella pratica, i bug del software attorno a una blockchain contano più degli attacchi alla catena stessa.
Questioni aperte: chi decide cosa conta come facile
La decisione spetta al team durante il triage: né la pagina né l’email definiscono «facilmente individuabile» oltre all’esempio dell’LLM. Il 23 ottobre restavano senza risposta diverse domande:
- Come verrà decisa la classificazione nei casi dubbi, e se chi ha segnalato il bug potrà contestarla.
- Quanti bug segnalati sono finiti finora nella nuova categoria. Finora non è stato pubblicato alcun avviso secondo la nuova regola.
- Se i risultati di agosto del Bitcoin Red Team abbiano toccato i repository di Bitcoin Core.
- Come verrà gestita in pratica la preoccupazione dei revisori sulle pull request pubbliche che avvisano gli attaccanti.
La prossima data da seguire è il primo avviso pubblicato con la nuova regola, e dopo di esso il rilascio della 32.0, che chiuderà il supporto alla 29.x. Intanto, questa settimana la corsa tra scansione e correzione si è vista anche attorno a due falle critiche in PHP che gli attaccanti stanno sondando, anche se non è stato dimostrato che alcuna piattaforma crypto sia stata colpita.