Le catene di exploit di Anthropic: il problema non è il modello, ma il ritardo delle patch

Fa paura che un'IA riesca a scrivere un exploit funzionante per Chrome, Safari e Linux? Meno della domanda noiosa che c'è dietro: quando verrà trovato il prossimo, chi lo avrà in mano prima che esca la patch?

Ecco cos'è successo. Il 27 ottobre il Frontier Red Team di Anthropic ha pubblicato un articolo di ricerca in cui spiega che, negli ultimi mesi, un modello di ricerca interno non ancora rilasciato ha trovato vulnerabilità critiche in browser e sistemi operativi. Secondo The Hacker News, il modello ha concatenato falle in exploit proof-of-concept funzionanti per Chrome, Safari, Android, Windows e Linux. Questi exploit sono stati costruiti in laboratorio dopo un prompt, non sono stati visti in attacchi reali, e ogni falla è stata segnalata prima al produttore, quindi sono tutte già corrette.

Un caso mostra com'è fatta la cosa. Il bug di Linux, CVE-2026-98432, è un use-after-free nell'handshake TCP presente da Linux 4.4. Frandroid riferisce che, dopo un primo prompt di un ricercatore, il modello ha scritto un exploit root da remoto: 48 minuti per far trapelare un indirizzo del kernel, altri cinque per prendere il controllo.

L'abilità è il titolo, ma non è la storia

Che i modelli trovino bug non sorprende più. Cambia l'economia. Una falla presente nel kernel Linux dal 2016 ha ottenuto un exploit root remoto funzionante in meno di un'ora di tempo del modello. Pensiamo che la risorsa scarsa nell'attacco fosse un tempo il lavoro di persone esperte, e che questa scarsità si stia erodendo.

La divulgazione di Anthropic mostra anche autocontrollo, cosa che merita un riconoscimento. L'azienda non ha pubblicato il proprio exploit, ha segnalato prima le falle ai produttori e dice di collaborare con società di sicurezza esterne per classificare e validare i risultati. Frandroid osserva che al 30 ottobre non era stata segnalata alcuna riproduzione indipendente. Eppure circa quaranta repository GitHub citano già la falla, e almeno sette si presentano come proof of concept. L'autocontrollo di un laboratorio non impedisce ad altri di costruire il proprio exploit a mano o con i propri strumenti.

La patch non è il traguardo

Tutti amano la frase secondo cui sono già tutte corrette. Noi andremmo cauti. La correzione per Linux era di quattro righe, scritta il 5 ottobre e presente nei kernel stabili l'11 e il 15 ottobre. Eppure la mattina del 2 novembre, secondo Frandroid, Ubuntu elencava ancora la sua correzione come «in corso» per le versioni da 22.04 a 26.10, anche se i pacchetti corretti erano già indicati nella sua pagina di tracciamento. Red Hat ha iniziato a distribuire le sue correzioni solo il 1° novembre e ha alzato la gravità a critica il 30 ottobre, dopo che lei e altri produttori avevano inizialmente valutato il bug tra 5,9 e 8,1.

Questo è il vero divario. Scrivere l'exploit ha richiesto a un modello meno di un'ora, mentre classificazione, punteggio di gravità, pacchettizzazione e riavvio del tuo server procedono ancora a velocità umana e burocratica. Red Hat ha avvertito che le aziende asiatiche devono applicare le patch più in fretta di fronte alle minacce dell'IA. Noi lo estenderemmo a tutti. Se un modello può comprimere lo sfruttamento, la difesa che conta è comprimere correzione e distribuzione.

Chi lo ottiene per primo decide tutto

Anthropic non ha rilasciato questo modello, il che è rassicurante e, sospettiamo, anche temporaneo. La questione è se i difensori otterranno strumenti equivalenti prima degli attaccanti. Qui siamo cautamente ottimisti: un laboratorio che segnala le falle ai produttori prima di pubblicare fa un favore a chi difende. Ma funziona solo se i produttori riescono ad assorbire il volume. Un'ondata di segnalazioni critiche ben validate può sommergere un piccolo team di manutentori quanto un attacco.

C'è poi un risvolto politico da guardare con occhio scettico. Radio France osserva che laboratori di modelli chiusi come Anthropic hanno chiesto una regolamentazione, che potrebbe favorire il loro modello di business rispetto a quelli aperti. A nostro avviso, la capacità offensiva è un argomento comodo per quell'agenda. Può essere sincero e restare comunque interessato.

Cosa fare lunedì

Il nostro consiglio è pratico, non apocalittico. Considera «patch disponibile» come un innesco di emergenza, non come un ticket per il prossimo trimestre. Se gestisci server Linux, controlla lo stato reale del tuo kernel, comprese le varianti cloud e HWE, e riavvia dopo l'aggiornamento; i container condividono il kernel dell'host. Dove la correzione non è ancora disponibile, le mitigazioni elencate da Frandroid (filtrare i pacchetti TCP con opzioni IPv4, disattivare MPTCP) riducono l'esposizione, anche se Red Hat sostiene che solo un kernel con la patch risolve il problema.

Il verdetto: non farti prendere dal panico per il modello, preoccupati con calma del tuo ritmo di aggiornamento. Il prossimo bug critico arriverà probabilmente più in fretta dell'ultimo, e vincerà chi accorcerà il tempo tra l'esistenza di una correzione e la correzione in esecuzione.