948 exploit di escalation locale in grado di ottenere l’accesso root: è il risultato che OpenAI attribuisce a una sessione di 30 ore della sua nuova pipeline automatizzata su Linux. L’azienda afferma che il sistema ha riprodotto 1.724 vulnerabilità, generato inoltre prove di concetto per 291 falle di divulgazione di informazioni e preparato patch per i problemi individuati. Il costo totale è stato di 1.213.430 dollari in crediti API.
La cifra descrive sia il salto di capacità che OpenAI vuole mostrare, sia un problema di sicurezza più immediato: individuare falle e produrre exploit può diventare più rapido, ma il valore difensivo dipende dalla convalida dei risultati, dal loro arrivo ai manutentori e dalla loro trasformazione in aggiornamenti installati. L’azienda afferma che ricercatori umani hanno esaminato i risultati e che ha già inviato segnalazioni e correzioni. I numeri, tuttavia, sono quelli di OpenAI; non esiste una verifica indipendente dei 948 casi.
Da 2.308 candidati a 948 exploit
Il test è stato condotto a metà ottobre con un modello di cybersicurezza non ancora pubblicato. OpenAI descrive un processo in cinque fasi: individuare il codice pertinente, riprodurre i risultati in un ambiente isolato, valutare se fossero sfruttabili, proporre patch e sottoporre i risultati a revisione umana.
Secondo i dati pubblicati dall’azienda e descritti in dettaglio da IT之家, gli agenti hanno selezionato 5.034 obiettivi di audit, per un totale di circa 2,8 milioni di righe di codice, quasi il 7% del kernel. Da questa analisi sono emersi 2.308 candidati. La fase di convalida ne ha riprodotti 1.724, circa tre quarti, in macchine virtuali isolate.
La valutazione successiva ha individuato 1.169 casi in cui gli agenti sono riusciti a ottenere un’escalation locale, ma il conteggio finale è sceso a 948 vulnerabilità distinte, dopo l’analisi delle varianti e il lavoro sulle patch. La differenza è importante: non si tratta di 948 segnalazioni iniziali né di 948 candidati non verificati, ma del numero finale che OpenAI presenta come vulnerabilità distinte con exploit funzionanti.
L’azienda afferma che gli exploit sono stati testati su una distribuzione Linux desktop con le consuete protezioni attive, tra cui SMEP, SMAP, KASLR e HARDENED_USERCOPY. Non ha pubblicato il nome della distribuzione né la versione del kernel utilizzata. Afferma inoltre che gli agenti hanno generato prove di concetto per 291 vulnerabilità di divulgazione di informazioni.
La sequenza trasforma l’analisi del codice in una catena di convalida, sfruttamento, correzione e revisione:
flowchart TD A["Seleccionar código"] --> B["Analizar candidatos"] B --> C["Validar en entorno aislado"] C --> D["Evaluar explotación"] D --> E["Proponer parches"] E --> F["Revisión humana"] F --> G["Informar a mantenedores"]
Il costo per falla diminuisce, ma resta elevato
I 1.213.430 dollari equivalgono, secondo OpenAI, a circa 1.279 dollari per exploit. IT之家 attribuisce 775.900 dollari alla fase di sviluppo degli exploit, la parte più costosa del processo. La cifra non va interpretata come un prezzo fisso per vulnerabilità: OpenAI riconosce che corrisponde al modello, alla configurazione e al flusso di lavoro di quel test e che non rappresenta il minimo possibile dopo aver ottimizzato il coordinamento degli agenti.
Il confronto con una sessione precedente offre una misura del cambiamento, ma non costituisce un esperimento controllato. A luglio, OpenAI ha utilizzato GPT-5.6 Sol e segnalato 166 vulnerabilità di escalation locale per 513.690 dollari. A ottobre, con un modello diverso e una pipeline rivista, il risultato è stato più di cinque volte superiore, nonostante nei tre mesi tra i due test il kernel avesse ricevuto un rafforzamento della sicurezza.
Il costo per risultato suggerisce che l’analisi automatizzata può aumentare il volume della ricerca senza richiedere per ogni risultato lo stesso impegno manuale di un audit tradizionale. Ma la spesa totale di questa sessione, superiore al milione di dollari, impone anche una cautela: non è uno strumento gratuito né un’operazione che qualsiasi team possa replicare facilmente. Inoltre, una parte significativa del lavoro non termina con la generazione di un exploit. Occorre eliminare i duplicati, verificare che la falla sia reale, comprenderne l’impatto e preparare una correzione che non introduca altri problemi.
Una capacità offensiva utile anche per correggere
OpenAI sostiene che il suo sistema non si sia limitato a trovare falle: ha anche proposto patch. IT之家 spiega che le prime versioni potevano essere ridondanti, incidere potenzialmente sulle prestazioni, discostarsi dalle convenzioni del progetto o non coprire varianti della stessa falla. L’azienda afferma di aver aggiunto vincoli e ripetuto il processo per migliorare la qualità; aggiunge che alcune patch generate hanno contribuito a individuare problemi in soluzioni precedentemente scritte da esperti umani.
La revisione umana è quindi parte integrante del meccanismo, non una formalità che si possa considerare conclusa con l’output del modello. I ricercatori devono valutare l’exploit, la correzione proposta e la gravità prima di informare i manutentori. Secondo i dati diffusi da OpenAI, durante i dieci giorni di analisi e revisione, 61 vulnerabilità erano già state corrette nel kernel upstream, 43 avevano patch in preparazione e altre 299 erano in discussione pubblica o in fase di segnalazione.
Il numero di correzioni conferma che il lavoro è in corso, ma non significa che tutte le vulnerabilità siano state riparate o che i sistemi che utilizzano Linux siano protetti. Una patch upstream deve essere integrata nelle distribuzioni e nei prodotti, quindi installata sui dispositivi interessati. OpenAI afferma di aver dato priorità alle falle gravi seguendo le indicazioni della comunità del kernel e che invierà le segnalazioni rimanenti insieme ai partner di Patch the Planet.
L’azienda stessa riassume con un avvertimento incisivo il rischio dei sistemi non aggiornati:
“For the near and medium term, having access to a low-privileged account on an operating system that isn't up-to-date on its latest available patches should be considered functionally equivalent to root access for a well-resourced threat actor.”
— OpenAI
Il salto di capacità non elimina i dubbi sulla misurazione
OpenAI afferma che gli agenti hanno utilizzato almeno dieci tecniche di exploit per Linux nuove per il team e per gli specialisti esterni consultati. Tra queste, The Hacker News elenca metodi per manipolare oggetti persistenti del kernel, migliorare l’affidabilità degli exploit e ottenere un’escalation con tecniche basate sui soli dati. L’azienda non ha pubblicato i dettagli completi per motivi di sicurezza.
Esiste anche un precedente che impone di leggere i numeri con cautela. ArtificialWatch riferisce che, in una sessione iniziale, 20 dei 200 successi segnalati avevano raggiunto l’obiettivo sfruttando una vulnerabilità diversa da quella assegnata. OpenAI afferma di aver corretto il problema aggiungendo un controllo. Questa revisione migliora il processo, ma non costituisce un audit esterno dei risultati finali.
Il test aggiuntivo nell’ambiente kernelCTF, con kernel rinforzato, ha prodotto 21 exploit di escalation locale e 25 prove di concetto di divulgazione di informazioni, con un costo approssimativo di 32.936 dollari e una durata di 112 ore, secondo IT之家. Times of AI confronta i 21 risultati con i 26 exploit di escalation zero-day che kernelCTF avrebbe accettato nell’intero 2026. Il contesto è diverso dall’analisi su una distribuzione desktop: quell’ambiente ha una superficie di attacco più ridotta e, secondo ArtificialWatch, è stata disattivata una mitigazione non supportata dall’ultima versione del kernel.
Per questo, confrontare direttamente i risultati dei test può esagerare ciò che il modello è in grado di fare da solo. Cambiano l’obiettivo, l’ambiente, le difese, la versione del modello e l’organizzazione degli agenti. Inoltre, non è noto pubblicamente quale modello sia stato utilizzato a ottobre: OpenAI lo identifica solo come un modello di cybersicurezza prossimo alla pubblicazione.
Cosa cambia per i manutentori e le aziende
Per chi mantiene software, l’effetto pratico non è che si debbano accettare automaticamente le patch generate dall’IA, ma che il volume di potenziali segnalazioni possa crescere rapidamente. Se i risultati arrivano più in fretta, la classificazione, la riproduzione e il coordinamento delle correzioni possono diventare il collo di bottiglia. OpenAI chiede di affiancare alla rilevazione automatizzata la generazione di patch; lo stato delle segnalazioni pubblicate mostra che questo lavoro richiede la collaborazione con i responsabili del kernel e il rispetto delle loro procedure.
Le organizzazioni che distribuiscono Linux affrontano l’altra metà del problema: ridurre il tempo che intercorre tra la disponibilità di una correzione e la sua installazione. Il Centro nazionale per la cybersicurezza del Regno Unito, citato da The Hacker News, ha avvertito che gli strumenti di IA difensiva possono accorciare il periodo tra la comparsa di una falla zero-day e la sua trasformazione in una vulnerabilità nota, ma che i sistemi resteranno esposti se la tecnologia non viene configurata correttamente e le correzioni non vengono distribuite. Ha inoltre chiesto di adeguare i processi interni di aggiornamento e test al nuovo ritmo di individuazione.
L’avvertimento ha anche una dimensione offensiva. Le stesse capacità che aiutano i difensori possono facilitare ad altri la ricerca e la preparazione di exploit. The Hacker News riferisce inoltre che Google Threat Intelligence Group ha osservato un aumento delle vulnerabilità divulgate, da 5.045 a gennaio 2026 a 10.740 ad agosto, e che quelle classificate ad alto rischio sono passate da 131 a 350 nello stesso periodo. Questi numeri descrivono le divulgazioni, ma non dimostrano che la causa sia l’IA; lo stesso articolo collega il cambiamento a una più ampia tendenza all’accelerazione nell’individuazione delle vulnerabilità.
OpenAI sostiene che, nel medio termine, i modelli potrebbero individuare falle complesse e aiutare a sfruttare vulnerabilità già divulgate. Per le aziende, il risultato di ottobre rende più rischioso un account locale con pochi privilegi quando il sistema è indietro con le patch. La domanda immediata non è quando verrà pubblicato il modello, dato che OpenAI non lo ha annunciato, ma quante delle segnalazioni in sospeso si trasformeranno in correzioni installabili.
Fonti: The Hacker News, IT之家, Times of AI, ArtificialWatch
