Nella seconda settimana di agosto 2026, uno sviluppatore Bitcoin pseudonimo noto come Calle ha pubblicato una frase che è rimbalzata per tutta l’industria: «Everything is broken, Bitcoin is burning» — tutto è rotto, Bitcoin sta bruciando. Dietro l’iperbole c’era un dataset. Il Bitcoin Red Team, squadra di volontari, aveva appena fatto passare Kimi K3 di Moonshot AI — un modello di frontiera cinese a pesi aperti, pubblicato appena due settimane prima — su praticamente l’intero ecosistema open source di Bitcoin: portafogli, applicazioni Lightning, librerie di pagamento e gli strumenti attorno a essi. Dopo circa 108 ore — tempo di campagna trascorso, lavorato da una squadra cresciuta fino a venticinque persone — su 501 progetti, la squadra aveva registrato 7 958 rilievi di sicurezza potenziali, 1 280 dei quali classificati alti o critici.
Quella singola campagna comprime tutto ciò di cui parla questo articolo: che cosa i modelli di IA possono ormai fare a una base di codice, chi li sta puntando su Bitcoin, che cosa trovano — e perché un regolamento europeo che comincia a mordere l'11 settembre 2026 trasforma tutto questo da una storia di ingegneria in una storia legale.
Gli attaccanti sono arrivati prima
Prima che i difensori si industrializzassero, lo hanno fatto gli attaccanti. La filiera open source da cui dipendono Bitcoin e la più ampia industria degli asset digitali è da anni sotto un assalto sostenuto e a movente economico — e l’ecosistema crypto ne è stato costantemente la vittima designata.
Nel settembre 2025, degli attaccanti hanno phishato il maintainer di chalk, debug e altre
sedici utility npm — pacchetti con miliardi di download settimanali complessivi — e hanno
distribuito un crypto-clipper che agganciava le API del browser e sostituiva in silenzio gli
indirizzi di destinazione nell’istante esatto in cui l’utente di un portafoglio approvava una
transazione, arrivando a scegliere gli indirizzi dell’attaccante per somiglianza visiva per
eludere il rilevamento. Settimane dopo, il worm Shai-Hulud ha aggiunto l’autopropagazione,
trasformando compromissioni isolate di maintainer in reazioni a catena. Nel marzo 2026 la
libreria Axios — dell’ordine di cento milioni di download settimanali — è stata dotata di
backdoor per poco meno di tre ore tramite un account maintainer dirottato, in parallelo alla
campagna TeamPCP che ha compromesso quattro progetti open source molto usati in una sola
settimana. E nel luglio 2026 degli attaccanti hanno infilato una backdoor travestita da
«telemetria» nell’SDK della blockchain Injective, cablando l’esfiltrazione di seed phrase e
chiavi private direttamente nelle funzioni di derivazione delle chiavi dei portafogli; la
pubblicazione automatizzata l’ha propagata a diciotto pacchetti in pochi minuti.
La direzione di marcia è misurabile. Il rapporto State of the Software Supply Chain 2026 di Sonatype ha contato oltre 454 600 nuovi pacchetti open source malevoli nel solo 2025 — un balzo del 75 % su base annua, che spinge il totale cumulato dei blocchi oltre 1,2 milioni. E anche gli strumenti sul lato offensivo evolvono: il Threat Intelligence Group di Google ha riferito nel 2026 di aver identificato, per la prima volta, un attore di minaccia che brandiva un exploit zero-day che il gruppo ritiene sviluppato con l’IA, destinato a un evento di sfruttamento di massa.
I repository open source sono presi di mira proprio perché sono lo strato di fiducia. Nessuno ha bisogno di violare la vostra infrastruttura se può avvelenare una dipendenza che installate volontariamente. E in nessun luogo quella leva è più grande che nel software che tocca chiavi e denaro.
La débâcle ColdCard
Poi, a fine luglio, il rischio astratto è diventato un rischio che cambia la vita. A partire dal 30 luglio 2026, un attaccante ha cominciato a svuotare quello che doveva essere il nascondiglio più sicuro di Bitcoin: la conservazione a freddo. In ondate successive — la più grande ha spazzato 1 082 BTC da 1 196 portafogli in soli 41 minuti, secondo il conteggio di Galaxy Research — la perdita ha raggiunto 1 367 BTC — circa 88,6 milioni di dollari — su 4 585 indirizzi generati su portafogli hardware ColdCard di Coinkite, al checkpoint di Galaxy del 1º agosto. Conteggi successivi hanno superato i 1 800 BTC e puntato verso i 130 milioni di dollari una volta inclusa una sospetta quarta ondata. (Correzione: una versione precedente di questa nota indicava 116 milioni di dollari — ripreso dalla copertura circolante e, in seguito, non riconducibile ad alcuna fonte che lo enunci, lo dati e lo definisca. I totali maggiori includono un’ondata ancora descritta come non confermata settimane dopo, e la stessa avvertenza di Galaxy merita di accompagnare la cifra — hanno abbinato gli indirizzi per pattern e non hanno usato potenza di calcolo per dimostrare che quei seed fossero deboli.) Secondo il meccanismo pubblicato, nulla di tutto ciò ha richiesto phishing, un dispositivo rubato o un accesso fisico di alcun tipo — le chiavi sono state ricostruite offline. Quelle esclusioni discendono da come funzionava il difetto; gli avvisi del produttore non affermano di aver indagato ed escluso ciascuna. Migliaia di holder di lungo periodo che avevano fatto tutto ciò che l’ortodossia dell’autocustodia prescrive — portafoglio hardware, chiavi offline, air gap intatto — hanno visto i risparmi di una vita lasciare indirizzi che solo loro avrebbero dovuto controllare. La causa radice era di una banalità devastante: un flag di build del firmware, distribuito nel marzo 2021, faceva sì che i dispositivi interessati saltassero il loro chip hardware dedicato alla casualità e ripiegassero su un debole PRNG software, facendo collassare l’entropia effettiva — fino a circa 40 bit sui vecchi Mk3 — abbastanza da permettere la ricostruzione offline delle seed phrase. La matematica di Bitcoin ha retto; il software che la avvolgeva no. Coinkite ha distribuito firmware d’emergenza, distrutto l’inventario vulnerabile e implorato gli utenti di migrare — ammettendo al contempo che nessuna patch può riparare un seed già generato su firmware vulnerabile.
Poi è arrivata la guerra delle narrazioni. Il CEO di Coinkite, Rodolfo Novak, ha inquadrato l’exploit come «a sober reality of the new AI paradigm» — una sobria realtà del nuovo paradigma dell’IA: la revisione del codice assistita dall’IA farebbe ormai emergere i bug latenti più in fretta persino degli esperti umani più navigati, e ogni firmware che sia o sia mai stato pubblico andrebbe presunto sotto scrutinio delle macchine, da parte di attaccanti e difensori allo stesso modo. Quell’affermazione è contestata, e l’onestà impone di dirlo. Nessun attaccante è stato identificato. Nessuna prova è emersa che un modello abbia trovato il difetto — la formulazione stessa di Coinkite è che «dobbiamo presumere» («we have to assume») che qualcuno abbia usato l’IA sul firmware pubblicato, e nello stesso documento l’azienda rivela che la propria revisione con IA, condotta settimane prima, «non ha trovato questo bug né nulla di serio» («did not find this bug or anything serious»). Una versione precedente di questa nota scriveva inoltre che specialisti di sicurezza avevano obiettato con durezza — che un flag di build che disattiva un RNG hardware è un fallimento di ingegneria umana che la revisione convenzionale avrebbe dovuto cogliere anni prima. Non siamo riusciti a sostenerlo alla riverifica: l’unico post che avevamo tracciato sta su un account sospeso, e il commentatore con nome più vicino che abbiamo trovato dava ragione a Coinkite anziché obiettare. L’argomento ci sembra ancora giusto — ma ora è nostro, non attribuito. In un senso, però, la disputa è marginale. Che un’IA abbia trovato questo bug oppure no, l’ecosistema ora sa che i modelli possono dimostrabilmente trovare bug esattamente di questa classe esattamente a questa velocità — e ha reagito come se la minaccia fosse reale. In pochi giorni, l’exchange Boltz ha sospeso le operazioni per giocare d’anticipo sui tentativi di attacco guidati dall’IA. E una controforza di volontari si è radunata.
L’ascesa del red team in Bitcoin
Il Bitcoin Red Team si è formato in pochi giorni dopo il drenaggio ColdCard: una controforza d’emergenza, volontaria, di sedici ricercatori guidati da Calle insieme al CEO di AnchorWatch Rob Hamilton, sostenuta da circa 40 000 dollari di calcolo IA e appoggiata da OpenSats, il cui nuovo programma di grant Code RED ora premia la divulgazione responsabile delle vulnerabilità nell’ecosistema. Il metodo abbina analisi guidata dall’IA e verifica umana — i modelli passano al setaccio portafogli, implementazioni Lightning e librerie; i ricercatori riproducono e valutano; i rilievi credibili vanno in privato ai maintainer prima che qualsiasi cosa venga pubblicata.
La traiettoria dei suoi numeri racconta che cosa fa l’IA all’economia della scoperta di vulnerabilità. Il primo sprint ha depositato 4 962 rilievi su 390 progetti in 27,5 ore — 85 critici e 635 alti, in media, secondo l’aritmetica di Calle al lancio, dell’ordine di un exploit critico per ricercatore all’ora. Giorni dopo, la scansione ampliata era a 7 958 rilievi su 501 progetti. La sintesi di Calle: la scansione di base di praticamente l’intero ecosistema open source di Bitcoin è completa, e i frutti a portata di mano sono stati colti.
I rilievi arrivano con una trama che conta più dei totali. Le vulnerabilità si concentravano nelle basi di codice più vecchie e poco riviste. Il software legato a Lightning — strutturalmente complesso, sensibile alle prestazioni, difficile da verificare — portava un’esposizione sproporzionata. La prevalenza di implementazioni in C è stata segnalata come rischio strutturale persistente. E la rapidità con cui un progetto rispondeva a una divulgazione privata si è rivelata una diagnosi in sé: la velocità di risposta, ha osservato la squadra, è un indicatore visibile della salute di un progetto. I progetti non mantenuti, hanno avvertito, non andrebbero considerati affidabili.
La campagna ha già prodotto un impatto reale e verificato. BTCPay Server — uno dei processori di pagamento Bitcoin self-hosted più diffusi — ha rilasciato la versione 2.4.2 il 7 agosto, correggendo un bypass critico dell’autenticazione a due fattori accreditato in parte ai ricercatori del Bitcoin Red Team — e ha poi confermato che il difetto era già stato sfruttato in natura per estrarre credenziali di portafogli Lightning. È l’intera tesi in un solo incidente: la vulnerabilità era reale, veniva usata, e la revisione assistita dalle macchine l’ha raggiunta prima di quanto avrebbe fatto la maggior parte degli umani.
Vale la pena dire direttamente che cosa è servito. Sedici volontari, circa 40 000 dollari di calcolo, poche settimane — e una disciplina che la maggior parte dei programmi di sicurezza finanziati non raggiunge mai: prima la divulgazione privata, la pubblicazione solo quando i maintainer avevano i rilievi, e il proprio tasso di riproduzione dichiarato in pubblico anziché sepolto. Hanno mappato un ecosistema rimasto non mappato per un decennio e hanno regalato i risultati. Qualunque cosa segua in questo articolo, quello è lo standard di riferimento per come questo lavoro va condotto, e l’ecosistema Bitcoin questo mese è più sicuro del mese scorso — grazie a loro.
Un vincolo di quel lavoro merita di essere enunciato chiaramente, perché viene abitualmente frainteso come una scelta metodologica. La squadra ha riferito che le restrizioni d’uso dei modelli statunitensi per la ricerca in sicurezza li hanno bloccati ripetutamente — spingendoli verso modelli a pesi aperti come Kimi K3 e GLM 5.2 di Z.ai, eseguibili in locale senza guardiani di policy. Kimi K3 non era un ripiego; per quel lavoro, in quel momento, era tra i migliori strumenti che avessero effettivamente il permesso di usare.
Quello è un fallimento di policy, non un fallimento di ricerca. La scelta degli strumenti nella ricerca in sicurezza è ormai plasmata meno dalla qualità dei modelli che da chi permette il lavoro tout court — e una squadra che allunga la mano verso il modello che il lavoro lo esegue davvero si comporta correttamente. Dovrebbe far riflettere i laboratori occidentali: la ricerca difensiva avviene comunque. L’unica domanda è sui modelli di chi — e se chi la conduce sia costretto in una cassetta degli attrezzi più stretta di quella che affrontano gli attaccanti.
Che cosa significano davvero 7 958 rilievi
Qui è dovuta onestà — e la squadra è stata la prima a doverla. Dei 7 958 rilievi, il 24,7 % aveva una proof of concept riproducibile — l’espressione è della squadra stessa — e il 29,4 % era stato segnalato upstream all’ultimo conteggio, cifre che la squadra ha pubblicato da sé invece di arrotondarle via. (Una versione precedente di questa nota scriveva «riprodotti dinamicamente»; era una nostra glossa, non loro, e il tasso di segnalazione indica rilievi inviati ai maintainer, non rilievi accettati dai maintainer.) Una valutazione congiunta dell’AI Security Institute britannico e del CAISI statunitense ha giudicato Kimi K3 capace ma lontano dall’infallibile — 32 % sui benchmark di sviluppo di exploit, davanti a GLM-5.2 ma ben dietro i più forti modelli chiusi, e senza ottenere esecuzione di codice arbitrario su nessuno dei 41 campioni testati.
Questo dunque non è un elenco di 7 958 falle sfruttabili in Bitcoin, e nessuno dei coinvolti lo ha sostenuto. L’inquadramento di Calle è stato schietto: i candidati costano poco, e se non riuscite a gestire il sovraccarico informativo che ne deriva, usate l’IA per smistarlo. È la lettura giusta, e indica il vero spostamento. L’IA ha reso la generazione di candidati quasi gratuita. Ciò che non ha reso gratuito è il giudizio che separa una vulnerabilità confermata, riproducibile e correttamente classificata da un’allucinazione dall’aria plausibile — lo stesso problema dell’«AI slop» in cui i maintainer open source, da curl in poi, stanno annegando.
La risorsa scarsa nella sicurezza si è spostata in silenzio dal rilevamento alla valutazione. È una proprietà della tecnologia, non un difetto di qualcuno — e una scansione che mappa un intero ecosistema e una valutazione firmata di una singola base di codice sono semplicemente mestieri diversi. La prima vi dice dove guardare. La seconda è ciò che un regolatore, un acquirente o un assicuratore accetteranno davvero. Ogni attore serio in questo campo — attaccante, difensore, maintainer, regolatore — sta ormai a valle di quel collo di bottiglia.
Bruxelles mette l’orologio
In questa collisione entra il Cyber Resilience Act dell’UE, e il suo tempismo difficilmente potrebbe essere più tagliente.
Dall’11 settembre 2026, l’articolo 14 del CRA obbliga i fabbricanti di prodotti con elementi digitali venduti nell’UE a notificare ogni vulnerabilità attivamente sfruttata di cui vengano a conoscenza — entro 24 ore per l’allerta precoce, 72 ore per la notifica completa e 14 giorni per la relazione finale — simultaneamente all’ENISA e al proprio CSIRT nazionale designato, tramite la piattaforma unica di notifica. Punto cruciale: questo si applica ai prodotti già sul mercato, non solo alle nuove versioni. Il regolamento si applica poi integralmente dall’11 dicembre 2027, portando con sé requisiti vincolanti di sicurezza fin dalla progettazione, il dovere dell’allegato I di effettuare prove e riesami di sicurezza efficaci e periodici, una documentazione tecnica contenente le relazioni di quelle prove, e obblighi di conservazione che si estendono per un decennio. Le sanzioni dell’articolo 64 arrivano a 15 milioni di euro o al 2,5 % del fatturato annuo mondiale totale, se superiore.
Ora mettete insieme le due metà di questo articolo. Le campagne assistite dall’IA stanno facendo emergere migliaia di vulnerabilità candidate negli ecosistemi open source nel giro di settimane — e alcune, come il difetto di BTCPay, vengono attivamente sfruttate, che è esattamente il grilletto di notifica del CRA. Un fabbricante il cui prodotto incorpora una dipendenza compromessa, o un difetto che una scansione IA fa emergere e un attaccante raggiunge per primo, non affronta più una tranquilla correzione ingegneristica. Affronta un orologio legale di 24 ore. E un fabbricante del tutto privo di un processo di scoperta potrebbe violare l’articolo 14 non per mancata notifica, ma per non aver mai saputo che c’era qualcosa da notificare.
Il corollario scomodo: molto del codice che oggi viene spedito dentro quei prodotti è scritto dalle macchine, e molta della revisione che gli viene applicata è svolta dagli stessi modelli che lo hanno scritto. Un codice scritto da un modello e revisionato dallo stesso modello non è stato revisionato da nessuno. Regolatori, acquirenti, assicuratori e team di sicurezza aziendali stanno convergendo sulla stessa domanda — e «il nostro modello ha controllato il proprio output» non è una risposta che qualcuno di loro accetti.
La confutazione come disciplina: il metodo CounterProof
Una scansione e una valutazione rispondono a domande diverse, e la seconda è dove siede la nostra practice. CounterProof non è stato progettato in un workshop come prodotto; si è accresciuto mentre mettevamo in sicurezza la nostra stessa infrastruttura di pagamento a crittografia a soglia — dove un difetto che sfugge non costa una relazione con un cliente: costa all’operatore i propri fondi.
Il vincolo che l’ha plasmato era l’opposto di quello del Red Team. A loro serviva ampiezza: 501 progetti, in fretta, su qualunque modello eseguisse il lavoro. A noi serviva che un singolo rilievo sopravvivesse all’avere torto in pubblico, su codice che custodisce il nostro stesso denaro. L’ampiezza perdona un falso positivo; una valutazione firmata no. Problema diverso, metodo diverso — e noi avevamo il lusso di scegliere gli strumenti, che è esattamente ciò che le restrizioni di policy descritte sopra negava a loro.
CounterProof affronta il collo di bottiglia della valutazione di petto, con un protocollo plasmato dalle modalità di guasto descritte sopra. Ogni valutazione è una revisione avversariale multi-lignaggio: famiglie di modelli indipendenti — non una seconda passata dello stesso — attaccano ogni rilievo e cercano di confutarlo, e i disaccordi si risolvono leggendo il codice sorgente, non votando.
Quest’ultimo punto non è una pretesa di modelli migliori. È un’affermazione su una proprietà misurata di tutti: il verdetto di un revisore è un campione, non una misura. Date allo stesso modello gli stessi byte due volte e non restituirà sempre la stessa risposta; ponete una domanda a più famiglie e falliranno in direzioni diverse — l’unica ragione per cui far girare più famiglie vale il costo. Abbiamo visto un modello «correggere» con sicurezza un riferimento regolatorio e sbagliare, mentre un modello senza accesso alle fonti rifiutava, correttamente, di rispondere. La lezione non è che un lignaggio sia superiore. È che un singolo lignaggio — qualunque — non può controllare sé stesso. Nulla viene spedito senza essere passato per la confutazione. Ogni rilievo che sopravvive viene poi confermato contro il codice sorgente reale — file e riga esatti, percorso di riproduzione, classificazione d’impatto, con citazioni risolte meccanicamente contro la revisione precisa esaminata — oppure etichettato esplicitamente come solo plausibile. Ogni rilievo nomina il gradino di evidenza effettivamente raggiunto — traccia nel sorgente, prova di compilazione, test o riproduzione dal vivo — e non ne lascia mai intendere uno superiore. E ogni rapporto porta un impegno permanente di ritrattazione: se un rilievo è dimostrato errato, viene ritrattato per iscritto.
In altre parole: dove la revisione dell’era IA genera rumore su scala industriale, l’output di CounterProof è deliberatamente l’opposto di una coda di triage. È una valutazione firmata, graduata per evidenza, sotto un identificatore di incarico persistente — strutturata per essere consegnata a un team di due diligence o a un assicuratore, o inclusa nella documentazione tecnica CRA come relazione di prova nella forma dell’allegato VII, punto 6), a riprova dell’obbligo di prova. L’indipendenza è strutturale: non emettiamo alcuna valutazione su codice scritto da CounterProof o da qualsiasi società del nostro gruppo — e la nostra stessa base di codice, in gran parte scritta dalle macchine, passa continuamente per lo stesso registro avversariale. Siamo stati il nostro primo cliente, e restiamo il più esigente.
Lanceremo a breve un nuovo servizio su CounterProof.io, che estende questa practice ai team che affrontano esattamente la convergenza descritta in questo articolo: codice scritto dalle macchine, avversari a velocità di macchina e l’orologio di un regolatore. Presto maggiori dettagli.
Dove va a finire
Tre previsioni, tenute con presa leggera.
Primo: il divario di triage si allarga prima di chiudersi. I modelli a pesi aperti continueranno a migliorare, scansioni come quella del Bitcoin Red Team verranno ripetute in altri ecosistemi, e il rapporto tra rilievi candidati e verificati peggiorerà prima che gli strumenti di valutazione e i metodi disciplinati recuperino. I progetti saranno sempre più giudicati — da utenti, assicuratori e acquirenti allo stesso modo — sulla loro velocità di risposta alle divulgazioni, esattamente come ha osservato Calle.
Secondo: il CRA diventa la funzione di forzatura che i bug bounty non sono mai stati. Le norme di divulgazione volontaria hanno prodotto per un decennio una copertura a macchia di leopardo; un obbligo di notifica in 24 ore con sanzioni scalate sul fatturato farà in diciotto mesi ciò che la buona volontà non ha fatto — e la domanda di prove di sicurezza periodiche, indipendenti e di qualità documentale ristrutturerà il mercato dell’audit attorno all’evidenza anziché ai distintivi.
Terzo, e più fondamentale per Bitcoin: un ecosistema il cui modello di sicurezza poggia sulla revisione aperta sta per scoprire se la revisione delle macchine conta. La risposta onesta: conta solo quando una parte indipendente è disposta a verificare il rilievo, graduare l’evidenza e firmare. Il rilevamento è stato automatizzato. La responsabilità no — e non può esserlo. È lì che vivono ora il valore, e la responsabilità.
CounterProof è una practice indipendente di revisione avversariale di Clavestra Capital Limited (Malta). Proof attesta; CounterProof confuta. counterproof.io — Questa pagina è una traduzione dell’originale inglese; in caso di divergenza prevale l’originale.
Fonti: avviso di sicurezza di Coinkite e copertura di Forbes, Bloomberg, CBC e Galaxy Research sull’exploit ColdCard (lug–ago 2026); divulgazioni del Bitcoin Red Team via Bitcoin Magazine, Decrypt, crypto.news, Coinpaper e Metaverse Post (ago 2026); note di rilascio di BTCPay Server 2.4.2; valutazione congiunta dei modelli UK AISI / US CAISI; Sonatype State of the Software Supply Chain 2026; Google Threat Intelligence Group, rapporto sull’attività di minaccia assistita dall’IA (2026); analisi StepSecurity della compromissione dell’SDK Injective (lug 2026); copertura degli incidenti della filiera npm (set 2025 – mar 2026); regolamento (UE) 2024/2847 (Cyber Resilience Act), artt. 13–14, 16, 69, allegati I e VII.