OpenAI e il kernel Linux: 948 exploit di escalation dei privilegi in una sola esecuzione

OpenAI ha pubblicato i risultati di un esperimento che pesa più di molti annunci di prodotto: una pipeline autonoma, basata su agenti AI, ha scandagliato il kernel Linux e ha prodotto 948 exploit distinti di escalation dei privilegi in locale, ciascuno accompagnato da una proposta di patch. Il tutto in una sola esecuzione, con un costo in API di circa 1,2 milioni di dollari.

Il numero fa rumore, ma il vero interesse sta nel metodo e nei limiti dichiarati dalla stessa azienda. Ti spiego che cosa è stato fatto, perché è importante per chi gestisce server e infrastrutture e quali cautele servono per leggere correttamente questa notizia.

Che cosa ha fatto la pipeline di OpenAI sul kernel Linux

Nel post A thousand fewer paths to root, pubblicato il 4 novembre 2026, OpenAI descrive un prototipo di sistema che unisce scoperta delle vulnerabilità, sfruttamento e correzione in un unico flusso automatico. Per la prova è stato usato un modello cyber non ancora rilasciato, lanciato sul kernel a metà ottobre.

Il risultato finale sono 948 vulnerabilità di tipo local privilege escalation, cioè falle che permettono a chi ha già un accesso con pochi permessi di diventare root. Ognuna è stata validata con un exploit funzionante e abbinata a una patch candidata.

Le cinque fasi del processo

La pipeline è organizzata a stadi. Prima ci sono gli agenti esploratori, che scelgono le porzioni di codice da controllare, privilegiando quelle raggiungibili da un utente poco privilegiato. Poi gli analisti segnalano i possibili bug, e gli agenti di triage costruiscono e verificano le prove di concetto dentro macchine virtuali con strumenti di rilevamento degli errori di memoria attivi.

Segue la valutazione dello sfruttamento reale e, per finire, la generazione e il controllo delle patch. Un team di ricercatori rivede tutto prima della segnalazione ai manutentori, partendo dai bug critici.

L’imbuto, numeri alla mano

Dai circa 40 milioni di righe di codice si è passati a 5.034 obiettivi di audit, pari a circa il 7% del totale, con una spesa di 3.426 dollari. Gli analisti hanno prodotto 2.308 segnalazioni candidate, costate 316.549 dollari, e di queste 1.724 sono state confermate come vulnerabilità reali, circa il 75%, con altri 73.330 dollari.

Dopo ulteriori screening sono emersi 1.169 exploit funzionanti, raggruppati per analisi di varianti in 948 correzioni distinte. Il costo complessivo in API è di 1.213.430 dollari, che OpenAI indica come limite superiore.

Perché questo risultato conta per chi difende i sistemi

Per anni la ricerca di exploit sul kernel è stata un lavoro artigianale, svolto da pochi specialisti con tempi lunghi. Qui la scala cambia: un singolo ciclo automatico ha prodotto in poche settimane un volume che prima richiedeva interi team. Per confronto, un’esecuzione di luglio con un modello precedente aveva trovato 166 escalation uniche spendendo 513.690 dollari.

Il salto di qualità non riguarda solo i difensori. Se uno strumento del genere funziona per chi corregge, lo stesso principio può essere usato da chi attacca, ed è per questo che OpenAI sottolinea di voler spingere i risultati verso le correzioni invece di pubblicare il codice degli exploit.

La logica difensiva è quella del programma Patch the Planet, lanciato a giugno nell’ambito dell’iniziativa Daybreak, che coinvolge partner di sicurezza e i manutentori del kernel. Prima di arrivare a loro, i risultati passano da una revisione umana, anche con il contributo di Trail of Bits.

Quando i modelli migliorano, il codice vecchio va riesaminato: ciò che sembrava sicuro ieri può non esserlo più oggi.

Altri dati di contesto

Sul bersaglio kernelCTF di Google la pipeline ha prodotto 21 escalation in 112 ore, con una spesa di circa 32.936 dollari. Su un campione di 166 exploit, OpenAI e gli esperti consultati hanno individuato 10 tecniche che ritengono nuove, ma i dettagli non sono stati resi pubblici e il dato non è verificabile in modo indipendente.

Il tema si inserisce in una serie di segnali che il nostro sito segue da settimane. Se vuoi un confronto, leggi come un modello Claude non rilasciato ha costruito exploit per i browser e per Linux, oppure il caso di Torvalds che usa Claude Code per riscrivere la page cache del kernel.

Che cosa i 948 exploit non dimostrano

La cifra va letta con attenzione, e il post di OpenAI stesso lo mette in chiaro. Il primo punto è che 948 non significa 948 falle corrette. Dieci giorni dopo la scansione, 61 problemi risultavano già sistemati nel kernel principale, 43 avevano patch in fase di staging e 299 erano in discussione pubblica.

Il secondo punto riguarda il tipo di attacco. Si parla di escalation locale, quindi serve già un account con pochi privilegi sulla macchina: non è una compromissione da remoto. Le macchine di prova avevano attive protezioni come SMEP, SMAP, KASLR e HARDENED_USERCOPY.

Il costo, poi, non è un prezzo fisso. Dipende dal modello, dal momento in cui si fotografa il codice e dall’impianto che coordina gli agenti.

L’errore da cui si impara

La parte più istruttiva riguarda un test iniziale. Gli agenti avevano dichiarato 200 escalation riuscite, ma la revisione umana ha scoperto che 20 erano arrivate a ottenere i privilegi di root sfruttando una vulnerabilità diversa da quella assegnata. Il controllo di successo era troppo permissivo, perché verificava solo di aver ottenuto una shell di root.

OpenAI ha corretto il problema stringendo i vincoli del compito e aggiungendo una verifica indipendente che l’exploit usi proprio il bug indicato. È una lezione utile per chiunque costruisca agenti autonomi: misurare il successo con un criterio troppo largo produce risultati gonfiati.

C’è poi una questione di fiducia nei numeri. Le cifre arrivano dal post dell’azienda e dai commenti di chi lo ha riassunto, e la parte sulle nuove tecniche è una dichiarazione di OpenAI non ancora confermata da terzi. Vale la pena aspettare la revisione dei manutentori del kernel prima di trarre conclusioni definitive sull’impatto reale.

Resta il fatto che il rapporto tra costo e risultato è molto cambiato: spendere circa 1.265 dollari per ogni vulnerabilità validata, stima ricavabile dai dati pubblicati, sarebbe stato impensabile con i metodi tradizionali.

Che cosa fare se gestisci server e infrastrutture

Per un professionista o per un’azienda la lettura pratica è semplice. Aggiornare in fretta il kernel e le distribuzioni conta più di prima, perché lo spazio di rischio si concentra tra la divulgazione di una falla e la sua correzione. Conviene inoltre rivedere periodicamente il codice più datato, dato che i modelli più recenti trovano ciò che i vecchi strumenti non vedevano.

Le patch generate da un’AI vanno trattate come bozze da sottoporre a una revisione avversariale, e ogni exploit segnalato da un agente andrebbe verificato per accertare che sfrutti davvero la falla prevista. Chi si occupa di sicurezza può approfondire anche l’exploit completo di Chrome ottenuto con XBOW e GPT-5.6, che mostra la stessa tendenza sul fronte dei browser.

Conclusioni

L’esperimento di OpenAI non dice che il kernel Linux sia improvvisamente insicuro, e nemmeno che i problemi siano risolti. Dice che la ricerca automatica di vulnerabilità ha raggiunto una scala industriale e che il collo di bottiglia si sposta dalla scoperta alla correzione e alla revisione umana.

Il dato più importante, per ora, è quello dei 61 problemi già sistemati su 948: la corsa è tra chi corregge e chi sfrutta, e la velocità di patching farà la differenza. Seguici per gli aggiornamenti su sicurezza e AI, e condividi questo articolo con chi amministra sistemi Linux nella tua azienda.