OpenAI AI: 948 exploit nel kernel Linux a costo di 1,2 milioni

Una pipeline automatizzata sviluppata da OpenAI, basata su un nuovo modello di cybersecurity, ha identificato e riprodotto 1.724 vulnerabilità nel kernel Linux, generando 948 exploit funzionanti per ottenere privilegi di root. L’operazione è costata 1,21 milioni di dollari in crediti API e ha prodotto anche possibili patch, attualmente sottoposte alla revisione dei ricercatori.

OpenAI ha sviluppato una pipeline autonoma specificamente progettata per individuare, verificare e preparare le correzioni delle vulnerabilità presenti nel kernel Linux. In un’unica esecuzione, condotta a metà ottobre con un modello di cybersecurity non ancora rilasciato pubblicamente, il sistema è stato in grado di produrre 948 exploit funzionanti capaci di consentire a un utente locale senza privilegi di ottenere l’accesso root.

kernel Linux: perché è importante

Il costo complessivo dell’operazione ammonta a 1.213.430 dollari, calcolato in crediti API utilizzati per alimentare il sistema automatizzato. I risultati dettagliati sono stati illustrati in un post sul blog di OpenAI, che descrive la metodologia impiegata, i costi sostenuti e le capacità dimostrate dal sistema.

Secondo OpenAI, l’aspetto più significativo non risiede solamente nel numero elevato di vulnerabilità individuate, ma nella possibilità concreta di automatizzare una porzione considerevole dell’intero processo. Questo include la prima analisi del codice sorgente, la riproduzione dei problemi rilevati, la valutazione della loro sfruttabilità e, infine, la generazione di patch correttive.

Il kernel Linux rappresenta un obiettivo particolarmente interessante per questo tipo di ricerca a causa delle sue dimensioni e complessità. Con oltre 40 milioni di righe di codice, costituisce il nucleo fondamentale dei sistemi operativi e delle infrastrutture utilizzate in una vasta gamma di applicazioni, dagli smartphone Android ai server cloud, passando per i supercomputer.

La sua architettura presenta un’ampia superficie d’attacco che comprende chiamate di sistema, funzionalità di rete, gestione del file system e driver hardware, rendendo complessa un’analisi completa ed esaustiva. Le vulnerabilità individuate appartengono prevalentemente alla categoria delle Local Privilege Escalation (LPE).

Le LPE sono difetti che possono consentire a un utente con privilegi limitati di ottenere autorizzazioni superiori, fino al livello di root. È importante sottolineare che lo sfruttamento di una vulnerabilità LPE richiede la presenza di un account utente o la capacità di eseguire codice sulla macchina target.

Il funzionamento della pipeline si articola in cinque fasi distinte, ciascuna affidata a specifici gruppi di agenti AI con compiti ben definiti. La prima fase è dedicata alla ricognizione del codice: gli agenti Scout hanno individuato 5.034 aree del kernel che meritavano un controllo più approfondito, analizzando complessivamente circa 2,8 milioni di righe di codice, corrispondenti a circa il 7% dell’intero progetto.

Questa fase iniziale ha comportato una spesa di 3.426 dollari in crediti API. Successivamente, gli agenti Analyst hanno esaminato le aree selezionate, identificando 2.308 possibili vulnerabilità in sole 12 ore. Il costo di questa attività è stato significativamente più elevato, raggiungendo i 316.549 dollari.

Tuttavia, la semplice segnalazione di una potenziale vulnerabilità non implica necessariamente la sua effettiva sfruttabilità. Per questo motivo, OpenAI ha introdotto una fase di validazione dinamica. Gli agenti Triage hanno generato proof of concept (PoC), ovvero programmi minimali progettati per riprodurre il comportamento anomalo, eseguendoli in macchine virtuali isolate.

Queste macchine virtuali utilizzavano un kernel strumentato con KASAN (Kernel Address Sanitizer), uno strumento che consente di rilevare accessi illegali alla memoria. In 30 ore, gli agenti Triage sono stati in grado di riprodurre 1.724 vulnerabilità, pari al 74,7% delle segnalazioni iniziali.

OpenAI sottolinea che solo il 3,1% dei candidati non validati derivava da un’analisi errata del modello AI, che aveva ipotizzato condizioni impossibili. Gli altri casi non sono stati confermati principalmente a causa della necessità di privilegi elevati, della difficoltà nel riprodurre determinate condizioni di gara o delle lunghe procedure di verifica richieste.

La fase di validazione ha comportato una spesa di 73.330 dollari. La quarta fase si è concentrata sulla valutazione dell’impatto potenziale delle vulnerabilità, con un costo di 44.194 dollari. Un agente di selezione ha ridotto il numero dei candidati a 313 potenziali vulnerabilità legate alla fuga di informazioni e 1.238 possibili LPE.

Gli agenti ExploitDev hanno quindi tentato di sfruttare queste vulnerabilità in macchine virtuali configurate con le protezioni standard presenti nelle distribuzioni Linux, tra cui SMEP, SMAP, KASLR e HARDENED_USERCOPY. Queste misure di sicurezza rendono più difficile la compromissione del kernel e la manipolazione della memoria.

Il sistema è riuscito a generare 291 proof of concept funzionanti per le vulnerabilità di fuga di informazioni e 1.169 exploit LPE. Il numero finale di 948 deriva da un’analisi volta a raggruppare gli exploit che facevano riferimento alla stessa vulnerabilità sottostante. Dopo aver eliminato i duplicati, OpenAI ha identificato 948 LPE distinte e preparato altrettante patch candidate.

La fase più costosa dell’intero processo è stata lo sviluppo degli exploit, che ha assorbito circa il 64% del budget totale (775.929 dollari). In media, la realizzazione di un exploit LPE riuscito è costata circa 360 dollari in crediti API. I tentativi fallimentari sono stati decisamente più onerosi, con 69 casi che hanno richiesto complessivamente circa 3.922 dollari ciascuno.

OpenAI ha precisato che l’obiettivo principale della ricerca era misurare le capacità del modello AI, non ottimizzare i costi. La spesa indicata rappresenta quindi un limite superiore, che potrebbe essere ridotto intervenendo sull’organizzazione degli agenti e sulle procedure di validazione.

Le 948 vulnerabilità individuate sono state associate a proposte di correzione, ma questo non significa che tutte le patch siano già state accettate dai responsabili dello sviluppo del kernel Linux. OpenAI ha seguito le indicazioni della comunità Linux, iniziando dalle vulnerabilità considerate più critiche.

Centinaia di segnalazioni e relative patch sono già state inviate ai maintainer, mentre per le altre l’azienda sta collaborando con i partner dell’iniziativa Patch the Planet, parte del programma Daybreak dedicato alla sicurezza del software open source. Nel frattempo, la comunità Linux ha continuato autonomamente il proprio lavoro.

Secondo i dati raccolti da OpenAI, nei dieci giorni necessari per completare la scansione e l’analisi manuale, 61 vulnerabilità LPE risultavano già corrette nel ramo principale del kernel, altre 43 disponevano di patch in preparazione e 299 erano oggetto di segnalazioni e discussioni pubbliche. Questo evidenzia un problema operativo: le segnalazioni generate automaticamente devono essere confrontate con il codice più recente per evitare di inviare ai maintainer vulnerabilità già corrette o duplicati di problemi individuati da altri ricercatori.

Cosa cambia e quali sono gli effetti

La revisione umana rimane quindi una componente essenziale del processo. OpenAI ha anche scoperto un problema nel proprio processo di verifica: durante una prima esecuzione, il sistema aveva dichiarato riusciti 200 exploit LPE, ma 20 di questi avevano ottenuto i privilegi di root sfruttando una vulnerabilità zero-day diversa da quella assegnata agli agenti.

L’azienda ha successivamente introdotto controlli indipendenti per garantire che ogni exploit utilizzi effettivamente il difetto indicato nel rapporto. La ricerca offre anche un confronto con le capacità dei modelli precedenti. A fine luglio, GPT-5.6 Sol aveva individuato e sfruttato 166 vulnerabilità LPE uniche, con una spesa complessiva di 513.690 dollari.

La nuova campagna di metà ottobre ha raggiunto quota 948, superando di oltre cinque volte il risultato precedente, nonostante nel frattempo il kernel avesse ricevuto numerose correzioni. Il costo medio per vulnerabilità è passato da circa 3.100 dollari a 1.279 dollari.

Un altro elemento rilevante riguarda la necessità di fornire al modello istruzioni e strumenti specifici per lo sviluppo degli exploit. Nei test con GPT-5.5 Cyber, OpenAI aveva raccolto 103 tecniche di exploitation in un formato facilmente utilizzabile dagli agenti. Su 63 candidati, questa integrazione aveva portato il tasso di successo dal 76,2% all’88,9%. Con GPT-5.6 Cyber, invece, il modello si è dimostrato più autonomo nell’individuare e applicare le tecniche necessarie.

Senza lo strato aggiuntivo di orchestrazione, ha raggiunto un tasso di successo del 92,1%, salito al 93,6% reinserendo le tecniche predefinite. Il miglioramento di appena 1,5 punti percentuali non giustificava, secondo OpenAI, la maggiore complessità del sistema. Gli agenti hanno inoltre dimostrato di poter sviluppare approcci non documentati in precedenza.

Analizzando un campione di 166 exploit, i ricercatori hanno identificato almeno dieci tecniche di exploitation nuove, che non erano note neppure agli esperti esterni consultati dall’azienda. Due riguardano nuovi oggetti persistenti utilizzati per riempire le cache del kernel, due nuove tecniche di gestione delle pagine di memoria, cinque metodi basati sulla manipolazione dei dati e un approccio che sfrutta la confusione dei tipi. OpenAI non ha pubblicato i dettagli tecnici per evitare di facilitare eventuali attività offensive.

Per valutare il potenziale della tecnologia, OpenAI ha confrontato i costi della propria pipeline con i premi storicamente offerti da alcune competizioni di sicurezza. Pwn2Own e TyphoonPWN hanno riconosciuto in passato rispettivamente 20.000 e 70.000 dollari per exploit LPE del kernel Linux. Applicando questi importi ai 948 exploit sviluppati dal sistema, si ottiene una valutazione teorica compresa tra 18,9 e 66,3 milioni di dollari.

Si tratta di un valore da 16 a 55 volte superiore al costo della campagna, anche se non rappresenta un ricavo effettivo né implica che tutte le vulnerabilità sarebbero state accettate dai programmi di bug bounty. Un secondo test ha riguardato kernelCTF di Google, un programma che utilizza una versione del kernel con superficie d’attacco ridotta.

In questo ambiente la pipeline ha prodotto 25 proof of concept per fughe di informazioni e 21 exploit LPE, impiegando complessivamente 112 ore e 32.936 dollari in crediti API. Nel 2026, al momento della pubblicazione del rapporto, kernelCTF aveva accettato 26 exploit LPE zero-day. Se tutte le 21 vulnerabilità individuate da OpenAI fossero state ammesse al programma, avrebbero potuto generare premi per circa 1,5 milioni di dollari, circa 45 volte il costo della ricerca.

Durante questa seconda campagna gli agenti hanno anche individuato una vulnerabilità nell’emulatore QEMU TCG utilizzato per i test. Il problema è stato ricostruito senza che gli agenti accedessero al codice sorgente di QEMU ed è stato successivamente sfruttato per ottenere un’escalation locale dei privilegi. L’analisi manuale ha permesso di verificare che il difetto era già stato corretto nel ramo principale del progetto, ma non nella versione utilizzata nell’esperimento.

Le conclusioni di OpenAI riguardano direttamente la gestione dei sistemi Linux. Secondo l’azienda, nel breve e medio periodo un account con privilegi limitati su un sistema non aggiornato dovrebbe essere considerato, in determinate condizioni, sostanzialmente equivalente a un accesso root per un attaccante dotato di risorse adeguate. Il rischio è particolarmente rilevante negli ambienti in cui più utenti o applicazioni condividono la stessa infrastruttura, come hosting, server, runner per l’integrazione continua e host che eseguono container.

In questi contesti, una vulnerabilità LPE può consentire a un aggressore che abbia già ottenuto un accesso limitato di compromettere l’intera macchina. Per ridurre le conseguenze di un eventuale exploit, OpenAI indica l’importanza di aggiornare tempestivamente il kernel, limitare l’esecuzione di codice sulle macchine sensibili e utilizzare sistemi di isolamento come Firecracker e gVisor.

L’installazione di una patch deve inoltre essere seguita dal riavvio del sistema, quando necessario, affinché venga effettivamente caricato il kernel corretto. La ricerca evidenzia anche la necessità di ripetere periodicamente le scansioni. Modelli più avanzati possono individuare difetti sfuggiti alle generazioni precedenti e, in progetti complessi, potrebbero essere necessarie più iterazioni di analisi e correzione per ridurre progressivamente il numero di vulnerabilità ancora presenti.

Fonte e approfondimento su kernel Linux: articolo originale.

* Contenuto realizzato con l'ausilio di sistemi di intelligenza artificiale.