Anthropic descrive cinque catene di exploit individuate con Claude

Cinque indagini, non un audit indipendente

Anthropic ha pubblicato un resoconto sull’impiego di un modello interno di ricerca, non ancora rilasciato, per cercare vulnerabilità in software molto diffusi. L’azienda descrive cinque catene di exploit: una in Chrome, una in Safari, un aggiramento della schermata di blocco di Android, un attacco remoto di denial of service a Windows e l’esecuzione remota di comandi su Linux. Sono risultati attribuiti da Anthropic al proprio lavoro, non esiti verificati in modo indipendente dalla documentazione disponibile.

Il resoconto include dettagli tecnici e afferma che le vulnerabilità sono state comunicate ai fornitori interessati. Anthropic sostiene che i problemi descritti siano stati corretti, ma il livello di dettaglio pubblico varia tra i cinque casi e non consente di considerare ogni catena una prova riprodotta da terzi. Inoltre, il modello utilizzato era interno e non pubblico: i risultati non dimostrano che chiunque possa ottenere le stesse capacità con un modello disponibile al pubblico.

È importante distinguere tra individuare un difetto, costruire una proof of concept e dimostrare un impatto in una configurazione specifica. Il documento presenta esempi di tutte e tre le fasi, ma la descrizione di Anthropic non equivale a una valutazione esterna del tasso di successo, delle risorse necessarie o della possibilità di generalizzare il metodo ad altri prodotti. E non basta, da sola, ad attribuire al modello l’intero lavoro di analisi, selezione e verifica che caratterizza una ricerca di sicurezza.

Chrome e Safari: catene che combinano più difetti

Per Chrome, Anthropic descrive una catena che iniziava con un problema di corruzione della memoria in V8, il motore JavaScript. Secondo il resoconto, l’attacco proseguiva sfruttando altri difetti per uscire dai limiti di memoria e dalle protezioni del browser, fino a raggiungere l’esecuzione di codice al di fuori della sandbox. La dimostrazione citata dall’azienda avviava l’app Calcolatrice su Chrome, con configurazione predefinita, in macOS. L’esempio illustra l’impatto attribuito alla catena in quelle specifiche condizioni; non dimostra che tutte le installazioni o versioni fossero vulnerabili.

La pubblicazione riferisce che Google ha assegnato 62 identificativi CVE ai problemi individuati e che, alla data del resoconto, questi erano stati corretti in Chrome 156; Anthropic li classifica come critici o ad alta gravità. L’azienda attribuisce a questo insieme 13 evasioni della sandbox e 21 vulnerabilità che avrebbero potuto compromettere il processo renderer. Sono numeri riportati da Anthropic: non vanno interpretati come 62 catene di exploit complete e indipendenti.

Per Safari, il resoconto presenta un attacco diverso, volto ad aggirare la politica della stessa origine, che normalmente impedisce a una pagina di leggere i dati di altri siti. Anthropic descrive una combinazione di un use-after-free in JavaScriptCore, l’accesso in lettura e scrittura al di fuori di un’area di memoria protetta e una vulnerabilità nel meccanismo IPC della sandbox. La catena avrebbe consentito di accedere ai dati locali del browser e di modificare un indicatore di sicurezza per disattivare la politica della stessa origine. L’azienda precisa che l’attacco non si basava sull’esecuzione arbitraria di codice, ma sulla combinazione di accesso alla memoria e modifiche allo stato del browser.

Il caso mostra perché un singolo difetto non sempre basta a descrivere il rischio complessivo. Alcune condizioni indicate sarebbero comportamenti previsti che, combinati con altre debolezze, hanno contribuito all’attacco. Anthropic afferma che Apple ha riconosciuto la segnalazione e implementato una correzione disponibile agli utenti. L’articolo non presenta una valutazione indipendente che permetta di stimare quanti utenti siano stati esposti o quale sia stato l’effettivo impatto dello sfruttamento.

Android, Windows e Linux: tre obiettivi e tre tipi di impatto

Su Android, Anthropic descrive un aggiramento che avrebbe permesso di estrarre foto e altri dati personali da un Pixel 9 bloccato. L’indagine ha combinato l’analisi di componenti open source, il reverse engineering di componenti di Google Play e test su un dispositivo fisico. La catena segnalata avrebbe superato diverse protezioni: il trasferimento USB, l’autorizzazione all’associazione, la verifica di un codice e un controllo sull’invio dei file. Secondo la pubblicazione, Google ha risolto il problema. L’estratto non fornisce un elenco completo delle versioni interessate o dei dispositivi esposti.

Su Windows, il problema individuato era una lettura fuori dai limiti nella gestione del protocollo QUIC da parte del kernel. Anthropic sostiene che un aggressore remoto potesse inviare pochi pacchetti a un server che risponde alle richieste HTTP/3 e provocarne l’arresto e il riavvio. L’azienda afferma che Microsoft ha corretto il difetto e gli ha assegnato l’identificativo CVE-2026-33096. Il lavoro descritto si basava sull’analisi di un eseguibile e su strumenti di reverse engineering; l’impatto indicato è un denial of service, non il controllo remoto del sistema.

Per Linux, Anthropic riferisce di una vulnerabilità di tipo use-after-free, causata da una race condition nello stack di rete del kernel e presente nei sistemi con un listener MPTCP. La catena descritta aveva due fasi: rivelare un indirizzo del kernel e poi alterare il flusso di controllo per eseguire un comando con privilegi di amministratore. L’azienda indica che alla vulnerabilità è stato assegnato l’identificativo CVE-2026-98432, che è stata corretta nel progetto e riportata nei rami stabili ancora mantenuti. Anthropic stima che la propria proof of concept impiegasse circa 48 minuti per ottenere un indirizzo del kernel e altri cinque per arrivare all’esecuzione dei comandi. Questi tempi si riferiscono a quella dimostrazione e non garantiscono prestazioni analoghe in generale.

I tre esempi non sono equivalenti: il caso Windows riguarda l’interruzione remota di un servizio, mentre quelli di Chrome e Linux descrivono l’esecuzione di codice o comandi nelle condizioni specificate. Il caso Android riguarda l’accesso ai dati senza sbloccare il dispositivo. Per valutare il rischio occorre considerare il prodotto, la versione, la configurazione e gli aggiornamenti installati, non soltanto la classificazione della gravità.

Il metodo: molti scanner e verifiche successive

Anthropic attribuisce parte dei risultati a una piattaforma che esegue numerosi agenti di analisi in parallelo. L’azienda afferma di misurare il contributo di ciascuno scanner e di monitorare la copertura del codice. Le strategie descritte comprendono la ricerca di difetti funzione per funzione, l’analisi di obiettivi specifici — come l’esposizione di dati — e la verifica che un’applicazione non violi il proprio modello di minaccia documentato.

Il resoconto menziona anche l’analisi automatizzata delle varianti: una volta confermato un problema, si cercano casi simili. Anthropic afferma che i risultati passano attraverso un processo standardizzato di verifica e classificazione del rischio. Questo è importante perché formulare un’ipotesi su un difetto non basta a dimostrare che sia riproducibile o sfruttabile. La pubblicazione, tuttavia, non descrive nel dettaglio tutti i criteri di accettazione, il numero di falsi positivi o un confronto controllato con team umani e strumenti alternativi.

Come raccomandazione per chi sviluppa software, Anthropic propone di integrare l’analisi di sicurezza durante la revisione delle modifiche al codice, oltre a correggere le vulnerabilità già note. La logica è preventiva: esaminare le nuove modifiche può aiutare a individuare difetti prima che entrino nel codice. Ma una raccomandazione o un’analisi automatizzata non garantisce che ogni problema venga rilevato né che il software risultante sia privo di vulnerabilità. L’efficacia dipende dall’ambito della scansione, dal contesto disponibile, dalla revisione umana e dalla risposta del team.

La pubblicazione sottolinea inoltre l’aumento del calcolo durante i test e la varietà degli scanner. Secondo l’azienda, queste scelte metodologiche e di configurazione hanno aumentato il numero di vulnerabilità individuate nel suo processo. Non significano che più risorse producano sempre risultati migliori o che un modello generi risultati corretti senza verifica. L’enfasi posta sulla convalida mostra che individuazione e conferma sono fasi distinte.

Che cosa cambia per chi difende i sistemi e che cosa non dimostra il resoconto

Il risultato più rilevante per i team di sicurezza è che, secondo Anthropic, un modello è riuscito a collegare diversi difetti in prodotti complessi e a costruire proof of concept con impatti differenti. La ricerca automatizzata potrebbe ampliare la capacità di esaminare il codice e accelerare l’analisi delle varianti. La stessa capacità può però avere anche un uso offensivo; i risultati rafforzano quindi l’importanza di gestire le patch, limitare l’esposizione e svolgere test autorizzati.

Anthropic sostiene che queste competenze, in passato concentrate in pochi team specializzati, possano diventare accessibili ai modelli con un intervento umano ridotto. È un’interpretazione dell’azienda basata sui propri esperimenti: il resoconto non presenta un confronto indipendente che quantifichi il lavoro umano necessario o la velocità del processo rispetto ai metodi abituali. Non permette nemmeno di concludere che un aggressore inesperto possa riprodurre facilmente tutte e cinque le catene.

Il documento identifica il modello come un sistema interno di ricerca non ancora rilasciato. Non è quindi corretto estendere automaticamente questi risultati alle versioni pubbliche di Claude o presumere che un’interfaccia accessibile riproduca lo stesso comportamento. L’accesso agli strumenti, il tempo di calcolo, le informazioni iniziali, le misure di sicurezza e la supervisione umana possono cambiare in modo sostanziale il risultato.

È particolarmente importante mantenere questa cautela quando si confronta la pubblicazione con altri incidenti di sicurezza. Il resoconto di Anthropic sulle vulnerabilità nei prodotti di terzi non conferma che un’azienda esterna abbia violato i sistemi interni di Anthropic e non fornisce dati su un presunto attacco di Cathedral. Si tratta di questioni distinte. Le informazioni disponibili qui non bastano per affermare chi avrebbe avuto accesso a quali sistemi, quanto tempo avrebbe impiegato o quali dati avrebbe ottenuto.

Per le organizzazioni che gestiscono software, la conclusione pratica non è affidarsi all’idea che un modello individui tutti i difetti. È opportuno mantenere un inventario degli asset, applicare gli aggiornamenti, controllare i componenti esposti e verificare i risultati in un ambiente autorizzato. Gli strumenti automatizzati possono essere d’aiuto, ma devono essere affiancati da controlli di accesso, revisione umana e procedure di divulgazione coordinata. Il resoconto presenta esempi concreti di rischi e correzioni dichiarate; non costituisce una garanzia di sicurezza né una dimostrazione universale delle capacità del modello.

Come valutare il valore operativo dei risultati

I dettagli tecnici sono utili perché permettono di distinguere i diversi tipi di impatto e di capire come più difetti possano rafforzarsi a vicenda. In una valutazione difensiva, una catena può essere più rilevante di un singolo problema se combina una vulnerabilità di memoria con un percorso che supera un confine di sicurezza. La priorità della risposta deve comunque basarsi sull’esposizione effettiva, sulle versioni installate, sulla disponibilità di correzioni e sulle possibilità di mitigazione, non solo su una dimostrazione appariscente.

I team possono usare i risultati pubblicati per controllare gli inventari e gli aggiornamenti dei prodotti interessati, senza tentare di riprodurre una catena contro sistemi altrui. Se si esamina una vulnerabilità, il lavoro dovrebbe svolgersi in laboratori controllati, con autorizzazione e su versioni predisposte per i test. Le proof of concept di sicurezza possono provocare effetti indesiderati se eseguite in produzione o contro infrastrutture di terzi.

La raccomandazione di integrare le revisioni nel processo di sviluppo non elimina la necessità di una difesa a più livelli. I controlli automatici possono rilevare schemi noti o segnalare codice sospetto, mentre l’analisi umana fornisce contesto e aiuta a valutare il rischio. Nessuno dei due meccanismi, da solo, garantisce una copertura completa. Il valore sta nel combinare individuazione, verifica, correzione e monitoraggio.

In sintesi, il resoconto presenta elementi dettagliati su ciò che Anthropic afferma di aver ottenuto con una ricerca interna e sui passaggi di segnalazione e correzione attribuiti ai fornitori. È un’indicazione rilevante sull’evoluzione della ricerca assistita da modelli, ma il suo ambito resta circoscritto: risultati dichiarati da un’azienda, relativi a sistemi specifici e a un modello non pubblico, senza una replicazione indipendente documentata nelle fonti disponibili.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.