I 500 zero-day di Claude Opus 4.6: cosa mostrano tre patch

Il 5 febbraio 2026 il Frontier Red Team di Anthropic ha pubblicato una ricerca in cui riferiva che Claude Opus 4.6, rilasciato lo stesso giorno, aveva individuato e convalidato più di 500 vulnerabilità ad alta gravità in software open source — senza strumenti specifici per l'attività, scaffolding personalizzato o prompting specializzato. Tre risultati sono descritti in dettaglio: un controllo dei limiti dello stack mancante in Ghostscript, una serie non verificata di strcat chiamate in OpenSC e un buffer overflow nel codificatore GIF CGIF che dipende da come si comporta la compressione LZW quando il suo dizionario si riempie. Anthropic afferma che tutti e tre sono ora corretti dai rispettivi manutentori e, secondo la sua versione, i bug sono stati individuati, convalidati e segnalati. Molti dei progetti sono mantenuti da piccoli team o volontari senza personale dedicato alla sicurezza, nota il post, perciò il carico di segnalazione e di patch è ricaduto su di loro. La voce dello stesso archivio relativa al risultato, classificata con gravità info e senza danni reali registrati, si trova nell'Orca AI Incident Archive accanto agli altri documenti di policy e divulgazione di febbraio 2026.

Cosa ha effettivamente pubblicato Anthropic

Il post si intitola "Evaluating and mitigating the growing risk of LLM-discovered 0-days" ed è attribuito al Frontier Red Team: Nicholas Carlini, Keane Lucas ed Evyatar Ben Asher come contributori paritari, con Newton Cheng, Hasnain Lakhani, David Forsythe e Kyla Guru. La pagina riporta una data di pubblicazione del 5 febbraio 2026 e una nota di modifica datata 6 febbraio 2026 che registra l'aggiornamento dell'elenco degli autori. L'archivio cita il post su red.anthropic.com, che ora reindirizza a anthropic.com/research/zero-days.

Il metodo conta più del numero in evidenza. Anthropic afferma di aver collocato il modello all'interno di una macchina virtuale con accesso alle versioni più recenti dei progetti open source e di avergli fornito utilità standard e gli strumenti che userebbe un ricercatore di sicurezza umano — debugger e fuzzer — ma nessuna istruzione su come usarli e, per usare le parole del post, «nessun harness personalizzato che gli avrebbe fornito conoscenze specialistiche su come individuare meglio le vulnerabilità». Ciò che veniva testato era il comportamento del modello out-of-the-box.

Il team ha circoscritto la ricerca ai bug di corruzione della memoria, ragionando sul fatto che un crash sia più facile da confermare rispetto a un errore logico. Anthropic è esplicita nel dire che si tratta di un filtro, non di una garanzia: «non tutti gli input che fanno andare in crash un programma sono vulnerabilità di gravità elevata». I crash sono quindi tornati al modello per la revisione critica, la deduplicazione e la riassegnazione delle priorità, e poi alle persone. «Per il nostro primo ciclo di risultati, i nostri stessi ricercatori di sicurezza hanno convalidato ogni vulnerabilità e scritto le patch a mano. Con l'aumentare del volume dei risultati, abbiamo coinvolto ricercatori di sicurezza esterni (umani) per aiutarci con la convalida e lo sviluppo delle patch». L'automazione delle patch, si legge nel post, era ancora in fase di sviluppo.

Tre bug e le patch che ne sono seguite

I tre esempi svolti condividono una struttura: uno strumento automatizzato aveva già fallito, e il modello ha individuato il bug ragionando su qualcosa di diverso dalla mutazione dell'input.

• Ghostscript, l'interprete PostScript e PDF. Il fuzzing e poi l'analisi manuale non hanno rilevato nulla. Il modello ha poi letto la cronologia Git del progetto, ha trovato un commit descritto nel post come l'aggiunta del "controllo dei limiti dello stack per i valori MM blend" ai charstring Type 1, ha dedotto che il codice precedente a quel commit fosse vulnerabile e si è messo a cercare altri punti di chiamata che non avevano ricevuto lo stesso trattamento. Ne ha trovato uno in gdevpsfx.c — il post cita la riga 292 — e ha creato un file che manda in crash il programma. Il repository lo conferma: il commit 87486fb801 di Chris Liddell, datato 5 settembre 2025, è intitolato "Type 1 charstrings: add stack bounds checking for MM blend values." Una correzione successiva di Ken Sharp, il commit 4e392a82 datato 26 gennaio 2026, aggiunge controlli dei limiti immediatamente prima di quella chiamata nel convertitore di font, registrata con il Bug 709080, il cui report è intitolato “Ghostscript Incomplete fix for Type 1 MM blend stack bounds check”. Un commit del 13 febbraio 2026 ha esteso i controlli dei limiti nello stesso convertitore. Nessuno dei messaggi di commit indica chi abbia segnalato il bug.

• OpenSC, un'utilità a riga di comando per i dati delle smart card. Qui il modello ha cercato chiamate a funzioni rischiose e ha trovato successive strcat operazioni che scrivono in un buffer filename di 4096 byte, dopo un calcolo della dimensione che sottraeva la lunghezza di una stringa di input ma poi aggiungeva ulteriori stringhe senza ricontrollare. Il post osserva che i fuzzer esistenti raggiungevano raramente quel percorso a causa delle precondizioni coinvolte. Il commit 33ab343a5c di OpenSC del 19 gennaio 2026 ha aggiunto un controllo che la stringa aggiunta sia esattamente di 64 byte, e la pull request #3554, unita il 25 gennaio 2026, ha sostituito le restanti strcat chiamate in tutto il progetto con strlcat; il suo autore ha definito la funzione una "calamita per qualsiasi strumento di analisi statica e per i CVE."

• CGIF, un encoder GIF. La libreria presumeva che i dati compressi fossero sempre più piccoli dell'input non compresso, cosa quasi sempre vera. Il modello ha ragionato sul fatto che LZW costruisce un dizionario di dimensione fissa e che, quando il dizionario si riempie, i codici clear inseriti nel flusso possono rendere l'output "compresso" più lungo dell'input — quindi un buffer dimensionato per N+2 codici poteva ricevere più di N+1. Il post afferma che anche una copertura di righe e rami del 100 per cento potrebbe non rivelarlo, perché serve una particolare sequenza di operazioni. La pull request #84 di CGIF, unita il 19 gennaio 2026 e rilasciata lo stesso giorno come v0.5.1, corregge esattamente questo: "I codici clear di reset mancavano nel calcolo del limite superiore della dimensione dei dati LZW."

Quelle correzioni sono arrivate prima della pubblicazione della ricerca — CGIF e OpenSC il 19 gennaio 2026, di nuovo OpenSC il 25 gennaio, Ghostscript il 26 gennaio — e Anthropic ha dichiarato nel post di aver «iniziato a segnalarle e di vedere arrivare le nostre patch iniziali» prima di rendere pubblica la ricerca. I repository registrano le modifiche al codice; non registrano chi ha presentato le segnalazioni, quindi il legame tra i risultati del modello e questi specifici commit si basa sul resoconto di Anthropic e su quanto strettamente i difetti descritti corrispondano ai diff.

Il ricercatore che ha affermato che il bug di OpenSC non era reale

Il vaglio pubblico delle singole scoperte non è iniziato né terminato con Anthropic. Il 14 febbraio 2026 K. Reid Wightman, ricercatore di sicurezza industriale che pubblica come @reverseics su infosec.exchange, ha pubblicato una revisione dell'esempio OpenSC sostenendo che il bug non potesse essere innescato: la stringa di input era già stata verificata come di 64 byte alla riga 5138, scriveva, il che limitava il buffer a 4095 byte, terminatore incluso. «Ho passato circa un'ora a esaminare il codice per smentire la loro scoperta», ha scritto.

Ha modificato lo stesso post il 17 febbraio 2026 per ritirare la contestazione. "Sembra che la versione del codice che stavo guardando avesse già una correzione per il bug (o i bug) scoperto da Anthropic", si legge nella modifica, prima di riconoscere il calcolo: "ma sì, senza il controllo strlen() su 'fp' l'overflow potrebbe effettivamente essere attivato. Ho mangiato la mia porzione di umiltà." Il controllo su cui aveva fatto affidamento era quello aggiunto a OpenSC il 19 gennaio 2026 — prima che Anthropic pubblicasse e prima che la maggior parte dei lettori sarebbe andata a cercare. L'archivio non segnala il record come contestato, e qui la contestazione è stata ritirata dalla persona che l'aveva sollevata.

Gli stessi maintainer di OpenSC hanno risposto alla stessa domanda nel loro tracker. Nella discussione #3575, aperta il 17 febbraio 2026 da un utente che chiedeva se le affermazioni di Anthropic fossero legittime, il maintainer di OpenSC frankmorgner ha risposto lo stesso giorno: «Abbiamo ricevuto due segnalazioni di bug da anthropic, entrambe verificate da esseri umani». Ha detto che le correzioni erano nella pull request #3554 e sarebbero state nella versione successiva, e che il commit 33ab343 era «una modifica introdotta dopo che anthropic ha segnalato il problema».

La metà sulla governance: sonde, blocco e 90 giorni

Ciò che rende questo un documento di policy anziché una semplice nota di ricerca è la seconda metà del post. Insieme al rilascio del modello, Anthropic afferma di aver introdotto, specificamente in ambito cyber, sonde che misurano le attivazioni all'interno del modello mentre genera una risposta, e di aver aggiornato i propri flussi di lavoro di applicazione per usare il rilevamento basato su sonde. Va oltre il rilevamento: "potremmo istituire interventi in tempo reale, incluso il blocco del traffico che rileviamo come malevolo". Anthropic ammette il costo — "Ciò creerà attrito per la ricerca legittima e parte del lavoro difensivo" — e afferma di voler lavorare con la comunità di ricerca sulla sicurezza su questo. Non vengono pubblicati tassi di rilevamento, tassi di errore né procedure di ricorso.

Il post sostiene anche che il calendario stesso della divulgazione sia ormai un problema. “Le finestre di 90 giorni standard del settore potrebbero non reggere di fronte alla velocità e al volume dei bug scoperti dagli LLM”, si legge, e avverte che i modelli “potrebbero presto superare la velocità e la scala persino dei ricercatori umani esperti”. È un fornitore che sostiene che la norma rispetto alla quale sarà giudicato debba essere sostituita, ed è la parte del resoconto con la portata più lunga.

Cosa è cambiato in seguito

Il 20 febbraio 2026 Anthropic ha aperto Claude Code Security come anteprima di ricerca limitata per i clienti Enterprise e Team, con accesso accelerato gratuito per i manutentori open source — la funzionalità è stata trasformata in prodotto quindici giorni dopo la ricerca. VentureBeat ha riportato il lancio e ha dichiarato di aver chiesto ad Anthropic il tasso di falsi positivi prima e dopo l'autoverifica, il numero di vulnerabilità divulgate con patch applicate rispetto a quelle ancora in triage, e le salvaguardie che distinguono l'uso da parte di attaccanti da quello dei difensori; ha riportato che il ricercatore principale del progetto non era disponibile e che l'azienda ha rifiutato di condividere specifici meccanismi di rilevamento degli attaccanti.

Anche le patch continuavano a spostarsi, e non sempre in una sola direzione. La correzione di CGIF per l'allocazione descritta da Anthropic è stata distribuita nella v0.5.1 il 19 gennaio 2026; il 21 febbraio 2026 la pull request #103 ha corretto un overflow di interi a 32 bit introdotto da quello stesso calcolo di allocazione, rilasciato come v0.5.2 il giorno successivo per GIF fino alla dimensione massima di 65.535 per 65.535 pixel. Riparare un calcolo dei limiti, a quanto pare, è di per sé una piccola fonte di bug sui limiti.

Leggere correttamente il numero

La frase di Anthropic stessa è "più di 500 vulnerabilità ad alta gravità". Axios, che l'azienda ha informato per prima, il giorno della pubblicazione le ha descritte come "più di 500 vulnerabilità zero-day precedentemente sconosciute", ciascuna convalidata da un membro del team di Anthropic o da un ricercatore di sicurezza esterno. Entrambe le descrizioni si riferiscono allo stesso insieme, ma solo una è la formulazione del fornitore, e nessuna delle due è accompagnata da un elenco, da una mappatura CVE o da una distribuzione della gravità. Il conteggio è di Anthropic, le valutazioni di gravità sono di Anthropic, e i tre progetti analizzati nel post sono gli unici che il pubblico può verificare.

L'analisi indipendente che ne è seguita ha per lo più preso il numero alla lettera e ha discusso di cosa significhi. Mitch Ashley di Futurum Group ha scritto il 24 febbraio 2026 che il risultato «conta più per ciò che il metodo rivela che per il conteggio», e che il vero vincolo è a valle: «Far emergere più vulnerabilità più rapidamente non riduce la superficie d'attacco. Crea una coda più grande davanti a un processo a valle che non è in grado di assorbire quel volume». Si tratta di una critica alla pipeline di divulgazione più che alla scoperta, e approda allo stesso punto sollevato da Anthropic riguardo alle finestre di 90 giorni.

Ciò che il fascicolo non stabilisce

L'archivio assegna a questo record una confidenza A, severità info, senza alcun danno reale registrato e senza flag di contestazione. Tale valutazione riguarda quanto bene l'evento è documentato, non quanto bene l'affermazione di fondo sia stata verificata, e la differenza vale la pena di essere tenuta presente. Nessuno al di fuori di Anthropic ha verificato i 500. Non è stato pubblicato alcun tasso di falsi positivi. Le patch per i tre progetti nominati sono reali e databili, e rappresentano la corroborazione più forte disponibile — ma corroborano tre esempi, non il totale.

Quello che resta, quindi, è un annuncio ben documentato con un nucleo verificabile e una parte restante non verificabile: un fornitore che dichiara una capacità, tre diff upstream che corrispondono alla sua descrizione dei bug e un’intenzione dichiarata di presidiare l’uso improprio di tale capacità a livello di modello. L’archivio lo classifica come policy, che è lo scaffale giusto. L’affermazione sulla capacità sarà risolta da chiunque pubblichi la quarta patch.