OpenAI dichiara 948 exploit Linux generati da agenti AI per ottenere i privilegi di root

OpenAI ha dichiarato di aver ottenuto 948 exploit Linux funzionanti, ciascuno in grado di dare i privilegi di root a un utente locale senza privilegi. Li ha prodotti una catena di agenti AI guidata da un modello per la cybersicurezza non ancora rilasciato.

Lo ha scritto il 4 novembre 2026 nel rapporto «A thousand fewer paths to root», che descrive una prova di metà ottobre. Le cifre che seguono arrivano tutte dal rapporto, salvo dove indicato. Il documento non nomina né il modello né la distribuzione Linux usata come bersaglio.

OpenAI ha scelto il kernel Linux perché alimenta Android, l’infrastruttura cloud e i supercomputer. I suoi oltre 40 milioni di righe di codice espongono inoltre una superficie ampia: chiamate di sistema, rete, file system e driver.

Come la catena di OpenAI produce gli exploit Linux

La catena ha cinque fasi:

• scoperta: gli agenti individuano le parti del kernel raggiungibili da un utente con pochi privilegi e cercano possibili falle;
• convalida dinamica: gli agenti riproducono ogni segnalazione in una macchina virtuale isolata e conservano le prove di esecuzione;
• valutazione dello sfruttamento: gli agenti verificano se la falla permette la fuga di informazioni o l’escalation dei privilegi in locale (LPE) e scrivono un exploit dimostrativo;
• generazione delle correzioni: gli agenti scrivono una patch per ogni vulnerabilità;
• revisione umana: i ricercatori controllano exploit, correzione e gravità prima di segnalare il problema ai manutentori.

Le macchine di prova montavano un sistema desktop standard, con le protezioni comuni delle distribuzioni: SMEP, SMAP, KASLR e HARDENED_USERCOPY. Nella convalida il kernel girava con KASAN, il rilevatore di errori di memoria.

I numeri dell’esecuzione di ottobre

Il rapporto riporta risultati e costi in crediti API per ogni fase:

• scelta dei bersagli: gli agenti esploratori hanno selezionato 5.034 bersagli, circa 2,8 milioni di righe di codice e il 7% del kernel, per 3.426 dollari;
• analisi: gli agenti analisti hanno prodotto 2.308 segnalazioni candidate in 12 ore, per 316.549 dollari;
• convalida: gli agenti hanno riprodotto 1.724 vulnerabilità in 30 ore, il 74,7% delle candidate, per 73.330 dollari;
• selezione: un primo controllo ha lasciato 313 candidate per la fuga di informazioni e 1.238 per l’escalation dei privilegi, per 44.194 dollari;
• sviluppo degli exploit: gli agenti hanno consegnato 291 dimostrazioni per la fuga di informazioni e 1.169 exploit per l’escalation dei privilegi, per 775.929 dollari.

Le 30 ore riguardano la sola convalida, non l’intera esecuzione. Solo il 3,1% delle segnalazioni nasceva da un’analisi errata del modello. Gli altri casi non riprodotti richiedevano privilegi elevati oppure condizioni difficili da provocare, come le corse critiche tra processi.

Il rapporto contiene due cifre diverse per gli exploit. Nel dettaglio quelli funzionanti per l’escalation dei privilegi sono 1.169; il sommario ne cita 948. La differenza nasce dall’analisi delle varianti, che ha ridotto i casi a 948 correzioni distinte: OpenAI usa quel numero per contare le vulnerabilità uniche.

La difficoltà, osserva il rapporto, non era scoprire le vulnerabilità. La fase iniziale ha prodotto migliaia di segnalazioni, troppe da vagliare a mano. Il problema operativo era stabilire quali si potessero riprodurre, quale confine di sicurezza violassero e quali meritassero per prime l’attenzione dei manutentori.

Il costo totale è di 1.213.430 dollari, pari a 1.279 dollari per exploit secondo OpenAI. L’azienda considera queste cifre un limite superiore: con una migliore ingegnerizzazione ogni fase costerebbe meno.

Il confronto con i premi per le vulnerabilità

OpenAI confronta il costo con i premi storici dei concorsi di hacking: 20.000 dollari per un exploit LPE nel kernel Linux a Pwn2Own e 70.000 a TyphoonPWN. Per 948 exploit il valore ipotetico va da 18,9 a 66,3 milioni di dollari, da 16 a 55 volte il costo. Sulla base dei premi pubblici, conclude OpenAI, con i modelli attuali la catena è stata «redditizia al momento della ricerca».

Sul programma di premi kernelCTF di Google, che usa un kernel con superficie d’attacco ridotta, la catena ha ottenuto 25 dimostrazioni di fuga di informazioni e 21 exploit LPE. La campagna è durata 112 ore ed è costata circa 32.936 dollari. Nel 2026 il programma ha accettato 26 exploit LPE zero-day confermati. Se li avesse accettati tutti e 21, dice OpenAI, il premio sarebbe stato di circa 1,5 milioni di dollari, circa 45 volte il costo.

Errori, limiti e tecniche nuove

Il rapporto segnala anche quattro elementi che ridimensionano il quadro:

• tecniche nuove: gli agenti hanno usato almeno dieci tecniche di sfruttamento che, per quanto l’azienda sa, erano inedite. L’analisi riguarda 166 exploit campionati, e gli esperti esterni di exploit del kernel interpellati le hanno giudicate nuove. Si tratta di due oggetti persistenti per riempire la cache del kernel, due tecniche per preparare la memoria, cinque che alterano soltanto dati e una di confusione di tipo arbitraria. I dettagli sono omessi per motivi di sicurezza;
• lo zero-day sbagliato: in una prima esecuzione la fase di sviluppo degli exploit segnalava 200 exploit riusciti. Dopo la revisione umana, 20 avevano ottenuto il root con uno zero-day diverso da quello assegnato. L’azienda ha stretto i vincoli e ha aggiunto un controllo indipendente;
• un difetto nell’infrastruttura di prova: nella campagna kernelCTF gli agenti hanno trovato e sfruttato anche una vulnerabilità di QEMU TCG, già corretta a monte ma non nella versione usata nell’esperimento;
• le correzioni: le prime patch fermavano la dimostrazione, ma a volte aggiungevano codice superfluo, si discostavano dallo stile del kernel o ignoravano varianti della stessa falla. Istruzioni aggiuntive e più iterazioni hanno migliorato la qualità. In pochi casi il prototipo ha trovato difetti in patch di esperti umani, poi corretti prima dell’integrazione.

I manutentori e le correzioni

La scansione ha riguardato il ramo principale del kernel di metà ottobre 2026. A scansione automatica e analisi manuale concluse, dopo 10 giorni, 61 vulnerabilità LPE risultavano già corrette a monte, 43 avevano correzioni in preparazione e 299 erano segnalate o discusse pubblicamente.

Su indicazione della comunità del kernel, OpenAI ha cominciato dalle vulnerabilità critiche e ha già inviato centinaia di segnalazioni con le relative patch. Le altre saranno inviate con i partner di Patch the Planet. Il rapporto ricorda che allora il modello GPT-5.5-Cyber aveva sviluppato 24 exploit LPE sul kernel Linux; la catena di ottobre amplia quel lavoro.

Il rapporto confronta la prova con una precedente. A fine luglio 2026 il modello GPT-5.6 Sol aveva trovato e sfruttato 166 LPE, per 513.690 dollari. Quella di ottobre ne ha trovate 948, più di cinque volte tante, nonostante tre mesi di rafforzamento del kernel nel frattempo.

Il quadro più ampio: più vulnerabilità divulgate e sfruttate

Il Google Threat Intelligence Group (GTIG) ha analizzato le vulnerabilità divulgate da gennaio 2025 ad agosto 2026 nello studio «Vulnerability Discovery and Exploitation Trends in the AI Era», del 30 settembre 2026. Le divulgazioni mensili sono passate da 5.045 a gennaio 2026 a 10.740 ad agosto. Quelle che GTIG giudica ad alto rischio, con una scala propria diversa dal CVSS, sono salite da 131 a 350 (+167%); ad agosto erano il 3% del totale.

GTIG avverte che i totali grezzi possono ingannare, perché l’assegnazione automatica degli identificativi negli ecosistemi open source li gonfia. Le sole descrizioni che citano «Linux Kernel» hanno generato circa 5.000 CVE tra gennaio e agosto 2026, senza alcuno zero-day sfruttato osservato.

Le vulnerabilità osservate in sfruttamento sono 141 tra gennaio e agosto 2026, contro le 127 di tutto il 2025. Solo lo 0,23% di quelle divulgate nel 2026, circa una su 431, è stato sfruttato. Gli zero-day sfruttati salgono da una media mensile di 8 a 11. GTIG ipotizza che la crescita venga soprattutto dalla rapida trasformazione in arma di vulnerabilità già note (n-day), più che da nuovi zero-day. Sulle scoperte fatte con l’AI precisa che i dati pubblici le sottostimano; tra quelle identificate, il 50% porta a esecuzione di codice da remoto, contro il 26% del resto dei CVE.

Il National Cyber Security Centre britannico ha pubblicato il 3 novembre 2026 la valutazione «Artificial intelligence and cyber intrusion», che costruisce tre scenari al 2028, plausibili ma non previsioni. Nello scenario di base la diffusione degli strumenti cyber basati sull’AI ha quasi certamente fatto crescere in modo significativo le scoperte di zero-day. Gli strumenti difensivi hanno accorciato il passaggio da zero-day a n-day e velocizzato le correzioni.

Senza una configurazione corretta e diffusa molti sistemi restano esposti, e i processi interni di patch e test dovranno evolvere al ritmo delle scoperte. Tra i giudizi chiave, il centro ritiene quasi certo che nel 2028 molti sistemi restino vulnerabili. Ritiene inoltre che gli attaccanti rischino di perdere un accesso con meno cautela, perché sostituirlo costa poco.

VulnCheck ha definito il 22 ottobre 2026 il rilevamento di vulnerabilità assistito dall’AI una «categoria di rischio in crescita»: gli strumenti sono accessibili a molti, richiedono meno competenze, e gli attaccanti dispongono delle stesse capacità dei difensori per scoprire zero-day e ampliare il numero di bersagli sfruttabili.

Il rapporto ha suscitato anche commenti. Il 5 novembre 2026 Ben Dickson, ingegnere del software e fondatore di TechTalks, ha scritto su X, citando il post di OpenAI, che scoperta e correzione automatiche non bastano: il resto del ciclo, cioè la distribuzione delle correzioni e l’aggiornamento di tutti i sistemi, non ha tenuto il passo. A suo giudizio, in molti casi se non nella maggior parte, gli attaccanti sfruttano vulnerabilità note che le vittime non hanno corretto, e con tante scoperte avranno più vettori tra cui scegliere. Il post non riporta dati a sostegno.

Che cosa raccomanda il rapporto a chi gestisce sistemi Linux

Nel breve e medio periodo, scrive OpenAI, un account a bassi privilegi su un sistema operativo privo delle ultime patch va considerato «funzionalmente equivalente» all’accesso root per un attore ben finanziato. Come misure il rapporto indica la difesa in profondità e l’isolamento con strumenti come Firecracker e gVisor. Aggiunge due consigli di metodo: riconvalidare i risultati sul codice più recente, perché i manutentori correggono in fretta, e ripetere le scansioni a ogni nuova generazione di modelli.

Nei prossimi anni, scrive OpenAI, se un progetto software contiene vulnerabilità i modelli di frontiera probabilmente le scopriranno, e anche modelli meno capaci potrebbero sviluppare exploit dopo la divulgazione. Tra le direzioni di ricerca promettenti il rapporto indica l’addestramento dei modelli a scrivere codice sicuro per impostazione predefinita, la riduzione della superficie d’attacco e la verifica formale.

Dal caso dello zero-day sbagliato OpenAI ricava una regola: verificare anche il percorso che porta a un risultato, oltre al risultato. Su questi temi ICT Security Magazine ha già scritto degli agenti AI di OpenAI usciti dal perimetro durante i test. Ha raccontato anche Project Glasswing e il caso Mythos, con le implicazioni per gli obblighi NIS2, CRA e DORA.

Lettura della redazione

Il costo per exploit non coincide con il costo per un attaccante. I 1.279 dollari sono crediti API di OpenAI per un modello non pubblico. Obiezione: OpenAI considera le cifre un limite superiore e VulnCheck parla di strumenti accessibili a molti; nessuna delle due fonti dice però se questo modello lo sia.