OpenAI: 948 exploit root per Linux generati in una sola esecuzione

OpenAI ha pubblicato oggi una ricerca, A thousand fewer paths to root, che descrive una pipeline — eseguita su un modello non ancora rilasciato, definito "upcoming" — capace di trasformare migliaia di bug candidati del kernel Linux in 948 exploit distinti e funzionanti di privilege escalation locale, in una sola esecuzione contro il kernel più recente. Il numero in prima pagina è pensato per allarmare, e ci riuscirà. Ma la cifra che dovrebbe davvero cambiare i vostri piani è più sommessa e sta più in basso nel testo: ogni exploit funzionante è costato circa 1.279 dollari, e su un bersaglio irrobustito l'intera operazione è risultata in attivo. Trovare e armare vulnerabilità è passato da artigianato a voce di bilancio.

Notizia in evoluzione — pubblicata alle 10:16 (09:16 UTC) del 5 novembre 2026. Aggiornata man mano che OpenAI e i manutentori del kernel pubblicano altro.

Cosa ha fatto davvero OpenAI

L'esecuzione è avvenuta a metà ottobre 2026 contro il kernel Linux attuale, con VM bersaglio compilate con Kernel Address Sanitizer e con le protezioni standard di una distribuzione desktop (SMEP, SMAP, KASLR, hardened usercopy). È un imbuto, non una magia, e ogni stadio perde volume:

Stadio	Risultato	Tempo
Delimitazione della superficie	~5.034 target di audit (~2,8M di righe, ~7% del kernel)	—
Scoperta	2.308 bug candidati	~12 ore
Triage / riproduzione	1.724 riprodotti (74,7%)	~30 ore
Exploitation	291 PoC di info-leak + 1.169 exploit root → 948 bug distinti	~10 giorni totali

Il 948 è un conteggio deduplicato: l'analisi delle varianti ha ricondotto 1.169 exploit root funzionanti ai bug sottostanti distinti, uno per ogni patch che lo chiuderebbe. Lungo il percorso gli agenti avrebbero usato almeno 10 tecniche di exploitation del kernel che esperti terzi hanno dichiarato di non aver mai visto — dettagli omessi "per ragioni di sicurezza". Come ha spiegato il team, la parte difficile non è quella che immaginereste:

La sfida operativa "non è stata la scoperta, ma stabilire quali risultati fossero riproducibili."

Il numero che conta è il prezzo

Un singolo laboratorio che produce 948 exploit root fa titolo. Un singolo laboratorio che li produce a un costo unitario che potete mettere a budget cambia il modello di minaccia. L'esecuzione di ottobre è costata 1.213.430 dollari di crediti API — che OpenAI presenta come limite superiore, il conto della valutazione, non il costo pieno della ricerca. La parte maggiore, 775.929 dollari, è andata alla fase di exploitation; un exploit riuscito è costato in media circa 360 dollari, con la coda lunga della spesa bruciata su race condition difficili da innescare.

Poi il conto dell'economia torna. Su una versione adattata del kernelCTF di Google — un bersaglio davvero irrobustito — un'esecuzione di 112 ore costata 32.936 dollari ha prodotto 21 exploit di privilege escalation, che OpenAI stima in circa 1,5M di dollari di ricompense potenziali, a fronte dei 26 zero-day LPE accettati dal kernelCTF in tutto il 2026. Applicando i payout standard dei bug bounty (Pwn2Own a 20.000 dollari, TyphoonPWN a 70.000) ai 948 si arriva a un ipotetico 18,9M–66,3M di dollari: da 16 a 55 volte il costo dell'esecuzione. Le cifre in dollari sono ipotetiche e autodichiarate. La direzione no.

Cosa non è

La versione onesta di questa storia è meno cinematografica del titolo, ed è quella contro cui dovreste pianificare.

• Sono privilege escalation locali, non esecuzione di codice da remoto. Gli exploit presuppongono che l'attaccante abbia già un account non privilegiato sulla macchina. Non fanno entrare nessuno da Internet. Quello che fanno è rendere la seconda metà di ogni intrusione — dal piede nella porta fino a root — economica e abbondante.
• 948 patch distinte non sono 948 fix rilasciati. Alla pubblicazione il conteggio era di 61 corretti upstream, 43 con patch in staging e 299 in fase di segnalazione e discussione. Il resto è in coda.
• Il successo dichiarato dall'agente non è successo. In un'esecuzione iniziale la pipeline dichiarava 200 exploit funzionanti; la revisione umana ha scoperto che 20 avevano raggiunto root tramite un bug diverso da quello assegnato. La correzione di OpenAI è stata un controllo indipendente che verifica che ogni exploit usi davvero la vulnerabilità assegnata. Quella frase è la più utile dell'intero testo, e ci torniamo.
• Il modello non è rilasciato. È descritto come "upcoming". Ma la riga previsionale di OpenAI è la parte da prendere sul serio: entro pochi anni si aspettano che "anche modelli meno capaci possano sviluppare exploit una volta divulgata la vulnerabilità".

L'inquadramento netto di OpenAI per chi difende: su un sistema non aggiornato, un account a basso privilegio va "considerato funzionalmente equivalente all'accesso root per un attaccante ben finanziato". È vero da anni, in sordina. Ciò che è cambiato è che "ben finanziato" ora significa un conto API a sette cifre, non un laboratorio statale — e chi ha letto il testo con spirito critico arriva allo stesso punto: trovare bug sta diventando economico e sistematico, quindi il vantaggio va a chi gira la pipeline contro il proprio codice per primo.

Remediation

Qui non c'è un singolo CVE da correggere — l'output è una classe di nuove LPE del kernel che arriveranno ai manutentori nell'arco di settimane. Quindi la risposta è una postura, non un numero di KB.

1. Trattate il patching delle LPE del kernel come una corsia veloce, non come una finestra di manutenzione. Una volta divulgata una falla, e resa armabile da un modello economico, la vostra esposizione è la distanza tra il commit del manutentore e il vostro riavvio. Seguite il flusso di fix che stanno arrivando ora (61 upstream, 43 in staging) e portate la cadenza di aggiornamento-kernel + riavvio a misurarsi in giorni per gli host esposti e multi-tenant.
2. Riducete la superficie "ha già un account locale". Questi exploit hanno bisogno di un piede nella porta. Date per scontato che ogni service account non privilegiato, ogni RCE in un'app web, ogni runner di CI e ogni host condiviso siano a un bug da root — perché quel bug ora è prodotto in serie. Minimizzate gli account locali, isolate i tenant e non eseguite workload non fidati accanto a ciò che vi sta a cuore.
3. Mettete in sandbox ciò di cui non vi fidate. La raccomandazione di OpenAI è l'isolamento — Firecracker, gVisor ed equivalenti — per limitare il raggio del danno quando (non se) un bug del kernel viene sfruttato sotto di voi. Se gestite calcolo multi-tenant, è il controllo che sopravvive al gap di patching.
4. Rianalizzate il vostro vecchio codice con strumenti nuovi. La stessa pipeline che trova questi bug per un attaccante li trova per voi. Codice che ha superato un audit umano nel 2022 non è stato analizzato da un modello del 2026. Date per scontato che l'arretrato ci sia e andate a cercarlo prima che qualcuno spenda 360 dollari per trovarlo ai propri fini.
5. Trattate le patch scritte dall'IA come bozze. OpenAI nota che i suoi fix generati "hanno richiesto iterazioni per essere minimali, conformi alle convenzioni e complete sulle varianti". Una patch che compila non è una patch corretta o completa. Rivedete la remediation IA come rivedreste la prima patch del kernel di un ingegnere junior.

Cosa non si sa ancora

• Quali siano i bug specifici dei 948, e quanti si sovrappongano a falle già note o già corrette — il dettaglio tecnico è omesso.
• Il nome del modello e la data di rilascio — è "upcoming", senza accesso pubblico dichiarato.
• Quanto l'economia pubblicata tenga fuori dall'infrastruttura di OpenAI — le cifre di costo sono autodichiarate e presentate come limite superiore.
• Se qualcosa di tutto ciò sia stato riprodotto da un terzo indipendente. Finora le uniche voci esterne sono gli esperti di kernel non nominati che hanno confermato la novità delle tecniche.

Chi dovrebbe girare questa pipeline per primo

La lezione sommessa del testo di OpenAI non è che l'IA sa scrivere exploit — lo abbiamo già raccontato più volte. È che a rendere affidabile l'output è la disciplina attorno all'IA: lo stadio di triage che ha riprodotto i bug in VM isolate e, soprattutto, il controllo indipendente che ogni exploit usasse la vulnerabilità assegnata — la correzione dell'errore 200-dichiarati, 20-mal attribuiti. Un motore offensivo senza quel livello di validazione produce spazzatura sicura di sé.

Quel livello di validazione è esattamente ciò attorno a cui è costruito un red team IA autonomo che gira sul vostro perimetro. Il motore di Zero Hunt usa uno swarm coordinato di 10 agenti i cui exploit sono scritti per bersaglio da modelli locali — ogni skill viene ribacktestata nell'AI Gym contro corpora come Vulhub e benchmark in stile kernelCTF prima di toccare una campagna in produzione, così ciò che raggiunge la vostra rete è validato, non autodichiarato. L'exploitation gira dentro container effimeri e irrobustiti con gVisor, con l'host dell'apparato mai nel raggio del danno; un umano approva ciò che conta, e ogni finding è firmato al momento della scrittura. Gira on-premise su modelli privati — nessun contatore per token a trasformare un'esecuzione da sette cifre in una questione di budget, e nessun terzo che possa limitarla o spegnerla. Puntate quel motore sul vostro codice prima che un modello economico, puntato da qualcun altro, lo punti su di voi.

E quando emerge una nuova strada verso root, la seconda domanda — quale di queste correggo per prima? — è quella in cui la maggior parte dei team annega. L'AI Remediation Advisor di Zero Hunt ordina i finding per reale sfruttabilità (CISA KEV, poi ciò che è stato davvero provato sfruttabile nella campagna, poi CVSS, poi EPSS), consegna la correzione esatta con note di rollout e rollback e un controllo compensativo per gli host che non potete correggere stanotte, e poi riverifica il fix con lo stesso exploit che ha dimostrato il problema — così "l'abbiamo corretto" è mostrato, non sperato. In una settimana in cui 948 nuove strade verso root sono appena state prodotte in serie, vincono i team che sanno provare quali porte hanno davvero chiuso.