Claude Opus 4.6 trova 500+ zero-day: l’open source entra nell’era dei bug scoperti dall’AI

Claude Opus 4.6 entra nella storia della sicurezza applicativa con un dato che, se confermato fino in fondo dalla comunità tecnica, riscrive le proporzioni del problema: oltre 500 vulnerabilità zero-day ad alta gravità individuate in software open source largamente adottato, spesso già sottoposto per anni a fuzzing e test intensivi. Non è un “record” da benchmark, né un esercizio accademico su bug sintetici: il messaggio di Anthropic è che un modello generalista, messo in una VM con utility standard, riesce a scovare falle reali là dove strumenti tradizionali e processi maturi avevano già consumato milioni di ore di calcolo. È una notizia che riguarda i difensori, ma anche chi governa la disclosure, chi mantiene progetti open source e chi, in azienda o nella PA, dipende da quelle librerie come da un’infrastruttura invisibile.

La sostanza, al netto del marketing inevitabile, è questa: la caccia ai bug non è più soltanto un tema di “coverage” e di casualità controllata, ma diventa sempre più un tema di ragionamento. E quando il ragionamento scala, cambia sia l’equilibrio della difesa sia la superficie d’attacco.

Dettagli tecnici semplificati: perché l’AI trova ciò che il fuzzing non vede

Anthropic descrive un’impostazione volutamente “banale” sul piano operativo: Claude lavora in una macchina virtuale isolata, con strumenti comuni (coreutils, Python e l’essenziale), senza harness personalizzati costruiti ad hoc per ogni progetto. La promessa implicita è forte: non serve un impianto di toolchain specialistici per far emergere bug importanti, perché la leva sta nella capacità del modello di leggere codice come lo leggerebbe un ricercatore esperto, ma con velocità e ampiezza superiori.

Il punto tecnico più interessante non è “Claude legge tanto codice”, ma come lo attraversa. Secondo la ricostruzione pubblicata, la strategia è basata su tre mosse che i fuzzer faticano a replicare da soli.

La prima mossa è l’analisi della storia del codice. Claude scorre commit e patch precedenti per identificare un pattern classico: una correzione applicata in una funzione o in un file, ma non replicata in tutti i percorsi equivalenti. In altre parole, individua fix parziali e poi caccia i rami che sono rimasti indietro. Questo è un comportamento “umano”, perché nasce dall’intuizione che il bug non è un evento casuale, ma un’abitudine che si ripete.

La seconda mossa è la comprensione dei vincoli logici. I fuzzer, anche quando sono sofisticati, spesso soffrono sui rami condizionali complessi: percorsi che richiedono combinazioni specifiche di stato, input e sequenze. Claude, invece, tenta di costruire l’input per soddisfare quel vincolo, arrivando a un crash non per caso ma per intenzione. È qui che la narrativa “supera i tool tradizionali” diventa plausibile: non perché il fuzzing sia inutile, ma perché viene aggirato il suo punto debole, cioè l’esplorazione cieca di spazi di input con geometrie proibitive.

La terza mossa è la produzione di un proof-of-concept mirato e la validazione con sanitizer. L’AI genera input per riprodurre il crash e gli analisti confermano l’impatto con strumenti come AddressSanitizer, deduplicando falsi positivi e concentrandosi su problemi ad alta severità. È un workflow che assomiglia più a un laboratorio di ricerca che a una pipeline automatica “premi un tasto”.

I casi citati: Ghostscript, OpenSC e CGIF

Anthropic porta esempi che hanno una qualità in comune: non sono “warning” superficiali, ma problemi legati a memoria, overflow e logiche algoritmiche in componenti usati ovunque.

Nel caso di Ghostscript, viene descritta una corruzione di memoria collegata a controlli incompleti nei percorsi che gestiscono determinati font Type 1. Il modello avrebbe notato che un precedente commit introduceva un controllo di bounds in un punto, ma che un percorso alternativo restava privo dello stesso controllo in un file specifico. La dimostrazione passa da un file PoC in grado di mandare in crash versioni vulnerabili. Il messaggio qui è doppio: da un lato, che bug potenzialmente sfruttabili restano in componenti maturi; dall’altro, che l’analisi del “dove è stato fixato, ma non ovunque” diventa un acceleratore di discovery.

OpenSC, libreria e toolchain legati alla gestione di smart card, viene citata per un classico buffer overflow in concatenazioni non controllate, con funzioni che sommano parti di path senza verificare la lunghezza complessiva. È un esempio quasi didattico, ma proprio per questo inquietante: un pattern noto, in un progetto serio, sfuggito non perché invisibile, ma perché nascosto dietro precondizioni non banali e percorsi poco battuti.

CGIF, libreria per la gestione di GIF, diventa invece un caso emblematico di vulnerabilità che nasce dall’interpretazione di un algoritmo: un overflow durante la gestione LZW in scenari in cui l’assunzione “compresso più piccolo di non compresso” smette di valere. Qui il valore aggiunto non è l’output, ma l’approccio: Claude ragiona sul funzionamento di un dizionario che si riempie, reset frequenti, sequenze che gonfiano la dimensione apparente e portano a un comportamento non previsto. È un tipo di bug in cui la coverage può essere alta e comunque insufficiente, perché ciò che manca non è l’esecuzione del ramo, ma la costruzione dell’input che lo rompe.

Perché 500+ zero-day cambiano le regole del gioco

Un singolo zero-day grave in un componente diffuso è già un incidente potenziale su scala globale. Cinquecento e più, anche se poi verranno normalizzati tra severità, duplicati o condizioni di sfruttamento, spostano la conversazione su un piano diverso: la vulnerabilità non è più un’eccezione, ma un inventario.

Questa mole di scoperte mette sotto pressione almeno tre sistemi.

Il primo è la manutenzione open source. I maintainer spesso lavorano con risorse limitate, e già oggi la triage di issue e report è una battaglia. L’AI aumenta il volume e può aumentare anche il rumore, ma qui Anthropic sostiene di aver fatto deduplicazione e priorità sulla gravità. Anche così, resta una realtà: servono workflow di gestione vulnerabilità pensati per un flusso AI-scale, non per il ritmo umano di una mailing list.

Il secondo sistema è la disclosure. Le regole “90 giorni” e le pratiche tradizionali sono nate quando il discovery era relativamente scarso e costoso. Se la scoperta diventa abbondante e rapida, la disclosure rischia di diventare o troppo lenta (lasciando finestre d’abuso) o troppo aggressiva (creando panico e patching impossibile). La domanda non è se cambieranno le regole, ma chi le cambierà per primo: comunità, vendor, CERT, o i threat actor.

Il terzo sistema è l’asimmetria attacco-difesa. Anthropic insiste sui safeguard e sul fatto che questa capacità vada messa in mano ai difensori. Ma la stessa capacità, se replicata o imitata, abbassa il costo per chi cerca exploit. Ed è qui che la notizia smette di essere “AI fa bene alla cybersecurity” e diventa “la cybersecurity deve assumere che l’AI farà bene anche a chi attacca”.

Le novità principali e cosa devono fare subito i soggetti compromessi

• Aggiornare il modello mentale: la vulnerabilità non emerge solo da fuzzing e scanning automatico, ma da analisi di commit, fix parziali e percorsi equivalenti. Le code review devono includere questa logica.
• Trattare la supply chain open source come infrastruttura critica: se componenti maturi contengono bug che resistono per anni, serve un presidio di patching e inventario dipendenze più rigoroso, con priorità reali.
• Preparare un workflow “AI disclosure-ready”: triage, deduplicazione, severity scoring e canali di coordinamento devono scalare, altrimenti il volume diventa un denial-of-service per la sicurezza stessa.
• Investire su validazione e riproducibilità: l’AI può proporre, ma in produzione serve sempre la prova con sanitizer, riproduzione deterministica e impatto chiaro sui sistemi reali.
• Rafforzare guardrail e monitoring interno: se la tua organizzazione adotta strumenti AI per security research, serve governance per evitare che la stessa pipeline venga abusata o esfiltrata.

Il contesto: AI come moltiplicatore di difesa e di abuso

Questa storia si incastra in un trend più ampio: l’AI sta diventando un moltiplicatore di capacità nei compiti “ragionati” del cyberspazio. La vulnerabilità discovery è uno di questi. L’impatto geopolitico e industriale non è astratto: l’open source è il pavimento di enterprise, cloud, infrastrutture e strumenti di automazione. Se un attore, statuale o criminale, può ridurre drasticamente il costo per trovare bug seri, allora la sicurezza non può restare “reattiva”.

C’è un nodo politico-tecnico che emergerà presto: la comunità accetterà modelli e laboratori privati come principali scopritori di zero-day? E, soprattutto, chi decide priorità e tempi quando il backlog esplode?

L’effetto collaterale potrebbe essere una spinta verso standard più duri per i provider di infrastruttura software, verso fondi e programmi per la manutenzione di progetti critici, e verso nuove pratiche di disclosure che tengano conto del fattore AI non come eccezione, ma come normalità.