GPT-6 Astra scrive exploit funzionanti: la finestra di patch è finita

Il 3 settembre 2026 OpenAI ha rilasciato GPT-6 Astra e, per la prima volta, ha classificato un proprio modello come Critical per la cybersecurity all'interno del suo Preparedness Framework. Quella parola non è marketing. Nella tassonomia di OpenAI, "Critical" è il livello che fa scattare restrizioni al rilascio perché il modello può aumentare in modo significativo le capacità di chi costruisce offensive cyber. Il numero che ha guadagnato la classificazione: su ExploitBench — un benchmark che misura se un modello sa trasformare una vulnerabilità nota in un exploit funzionante — Astra ha ottenuto il 100%, contro il 78,5% del precedente modello di frontiera, GPT-5.6 Sol.

Nella stessa settimana i difensori applicavano la patch per CVE-2026-85046, uno zero-day type confusion attivamente sfruttato nel motore V8 di Chrome. Questi due fatti appartengono alla stessa frase, e quasi tutta la copertura li ha tenuti separati. Il benchmark su cui è stato misurato Astra è stato costruito, in parte, da vulnerabilità V8 reali divulgate tra giugno e agosto 2026 — esattamente la classe di bug che, in questo momento, viene sfruttata nei browser dei tuoi utenti. Il risultato di laboratorio e l'incidente reale sono lo stesso problema, a sei settimane di distanza.

Cosa significa "Critical" quando GPT-6 Astra fa 100% su ExploitBench

Togli il rumore del lancio e leggi i numeri pubblicati da OpenAI e dalle testate indipendenti, perché descrivono un salto di capacità, non un incremento:

Benchmark	GPT-5.6 Sol	GPT-6 Astra	Cosa misura
ExploitBench	78,5%	100%	Trasformare un CVE noto in un exploit funzionante
ExploitGym	30,3%	42,4%	Sviluppo end-to-end di un exploit
Port V8 contamination-controlled	5,5%	39,0%	Esecuzione di codice arbitrario su 20 bug V8 gravi divulgati giu–ago 2026

L'ultima riga, riportata da CSO Online, è quella che dovrebbe togliere il sonno a chi gestisce una flotta di browser. "Contamination-controlled" significa che il test è stato costruito da vulnerabilità divulgate dopo il cut-off di addestramento del modello: Astra non poteva aver memorizzato la fix o un proof-of-concept pubblico. Doveva ragionare dal bug fino all'esecuzione di codice arbitrario — e ci è riuscito nel 39% dei casi, contro il 5,5% di Sol, usando meno token di output. Durante quella valutazione, secondo The Hacker News, il modello ha fatto emergere due zero-day fino ad allora sconosciuti in software non specificato, che OpenAI sta comunicando ai manutentori.

Due zero-day come effetto collaterale di un giro di benchmark. È la parte che non entra in una slide.

La finestra di patch era già una finzione. L'exploit con AI la elimina del tutto

I difensori si sono retti per due decenni su un'ipotesi rassicurante: dopo la divulgazione di una vulnerabilità c'è una finestra — ore, a volte giorni — prima che un exploit affidabile sia pubblico. In quella finestra vivono il patching, il virtual patching e l'incident response. Si restringe da anni. Astra è come appare quando si restringe a zero.

Prendiamo CVE-2026-85046 in concreto. Salvatore Gulizia ha segnalato a Google il type confusion in V8 il 4 agosto 2026. Google ha rilasciato Chrome 152.0.7977.82 il 3 settembre e CISA lo ha aggiunto al catalogo KEV il 4 settembre come attivamente sfruttato — il sesto zero-day di Chrome del 2026, secondo Help Net Security. Storicamente la parte difficile per un attaccante di fascia media non era scoprire che esisteva un type confusion in V8 una volta uscita la fix; era scrivere un exploit stabile partendo dal diff della patch. Quel lavoro era il fossato.

"Abbiamo applicato la patch entro 48 ore dall'advisory. Eravamo a posto." — ogni post-incident review, finché lo step di scrittura dell'exploit smette di richiedere una settimana a uno specialista e inizia a richiedere un pomeriggio a un modello.

Non è un uplift ipotetico. Il team di threat intelligence di Google ha documentato un gruppo criminale che ha usato un LLM per costruire un exploit di bypass del 2FA per uno strumento di amministrazione open-source — lo script portava un CVSS score allucinato e la formattazione tipica di un LLM, e Google ha lavorato con il vendor per bloccare lo sfruttamento di massa. Era un caso di metà 2026, con un modello più debole, e già funzionava abbastanza bene da essere intercettato in the wild. Astra è la capacità che quel gruppo avrebbe voluto avere.

Perché le protezioni di OpenAI non spostano il tuo rischio

OpenAI ha fatto le cose responsabili. La versione rilasciata di Astra è limitata a revisione del codice e patching sicuri e rifiuta di produrre proof-of-concept di exploit; l'azienda ha inoltre annunciato "Daybreak for Frontline Defenders", 1 miliardo di dollari promessi in accesso agevolato per i difensori delle infrastrutture critiche. Bene. Nulla di tutto ciò cambia i conti del difensore, per tre motivi:

• Ora è noto che la capacità esiste ed è raggiungibile. Un filtro di rifiuto su un'API è un dosso, non un muro — jailbreak, fine-tune e modelli open-weight che inseguono la frontiera a qualche mese di distanza ereditano la stessa capacità di ragionamento di fondo. Il 100% su ExploitBench è stato misurato senza le protezioni di produzione: quella è la capacità reale, e non torna indietro.
• Al tuo avversario non serve Astra nello specifico. Gli serve un exploit per il CVE che non hai ancora patchato. Il caso GTIG dimostra che un modello più debole supera già quell'asticella per i bug di tipo logic-flaw.
• I difensori ricevono il sussidio per leggere e patchare; gli attaccanti ottengono la capacità di scrivere. L'asimmetria è che la generazione dell'exploit è la metà offensiva, ed è esattamente la metà che un filtro di rifiuto prova a trattenere — mentre la capacità grezza filtra verso ogni attore che fa fine-tuning di un modello aperto su corpora pubblici di exploit.

La risposta corretta non è sperare che i filtri reggano. È presumere che l'attaccante possa generare un exploit funzionante per qualunque CVE divulgato nel tuo ambiente, il giorno stesso della divulgazione, e costruire la cadenza di validazione attorno a *quell'*ipotesi.

Remediation

Per la vulnerabilità viva di questa storia — CVE-2026-85046, il type confusion di Chrome V8 attivamente sfruttato — ecco il runbook. Un RCE in V8 ottiene esecuzione di codice dentro la sandbox del renderer di Chrome; da solo è grave, e concatenato con un bug di sandbox-escape diventa compromissione completa dell'host. Trattalo come il primo e difenditi dal secondo.

1. Sono interessato? Controlla la versione del browser sull'intera flotta, non solo sulla tua macchina:

# Linux
google-chrome --version
# macOS
/Applications/"Google Chrome".app/Contents/MacOS/"Google Chrome" --version
# Windows (PowerShell)
(Get-Item "C:\Program Files\Google\Chrome\Application\chrome.exe").VersionInfo.ProductVersion

Qualunque versione precedente a 152.0.7977.82 è vulnerabile. Includi i browser derivati da Chromium (Edge, Brave, Opera, app Electron) — imbarcano il proprio V8 e sono in ritardo rispetto al canale stable di Google.

2. Patch — versioni corrette esatte. Aggiorna a Chrome 152.0.7977.82 (Linux) o 152.0.7977.82/.83 (Windows/macOS). Poiché il rollout è a scaglioni, non aspettare l'auto-update: forzalo da chrome://settings/help, o distribuiscilo tramite il tuo canale di gestione (Google Admin console, Intune, Jamf) così che l'intera flotta si muova insieme. Riavvia il browser — l'aggiornamento non si applica finché Chrome non viene riavviato.

3. Non puoi patchare subito? Controlli compensativi.

• Imponi la Site Isolation (è attiva di default; verifica che non sia disabilitata via policy) così che un renderer compromesso non possa leggere facilmente dati cross-site.
• Disabilita il JIT per i siti non fidati dove la tua policy lo consente (--js-flags=--jitless ha un costo di compatibilità; limitane l'ambito). Gli exploit type confusion si appoggiano molto alle primitive del JIT.
• Stringi l'egress: le catene drive-by V8 scaricano payload di secondo stadio. Blocca al proxy i domini appena registrati e mai visti.

4. Cerca segni di compromissione. Gli zero-day V8 arrivano via drive-by — una pagina HTML/JS artefatta (MITRE ATT&CK T1189 Drive-by Compromise, T1203 Exploitation for Client Execution). Cerca:

• Processi renderer di Chrome che generano figli inattesi o scrivono su disco (follow-on di injection, T1055).
• Connessioni in uscita da un host con browser verso ASN mai visti subito dopo la visita a una pagina — il classico beacon di staging.
• Burst anomali di DNS-over-HTTPS da endpoint che storicamente navigano solo verso destinazioni note.

5. Eradica e verifica. Se un host mostra segnali di post-exploitation, isolalo, ruota le credenziali o i token di sessione che erano vivi in quel profilo browser (i cookie SSO sopravvivono a una patch) e conferma che la versione corretta sia effettivamente in esecuzione dopo un riavvio — un binario patchato su disco con un processo vecchio ancora in memoria non è patchato.

Cosa succede quando il difensore fa girare lo stesso motore

La lezione scomoda di GPT-6 Astra è che il vantaggio offensivo va ora a chi riesce a generare più in fretta un exploit funzionante per il tuo ambiente specifico. Un pentest trimestrale e uno scanner basato su firme stavano già perdendo quella gara. Contro un avversario capace di weaponizzare un CVE divulgato il giorno stesso, non sono nemmeno in gara.

Zero Hunt è nato sull'ipotesi con cui si chiude questo articolo. Il suo swarm di 10 agenti AI — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, sotto un AI Controller — non pesca exploit da ExploitDB. Genera codice di exploit per-target con un LLM locale, la stessa capacità di ragionamento che descrivono i numeri di ExploitBench, puntata sulla tua superficie d'attacco invece che su un benchmark. Ogni skill candidata viene ri-testata nell'AI Gym — 142+ skill auto-evolutive validate contro Vulhub, NYU CTF Bench, Cybench e 314 task black-box basati su CVE — prima di toccare una campagna di produzione, e ogni finding è firmato con ECDSA per la catena probatoria. Le campagne change-triggered fanno sì che un asset appena esposto, o un CVE appena divulgato in software che usi, lanci una validazione completa entro un'ora — non il trimestre prossimo.

Il modello di deployment è la parte che CVE-2026-85046 e Astra rendono insieme non negoziabile: il motore gira 100% on-prem, con l'LLM locale all'appliance — nessun callback verso il cloud, nessuna API di modello esterna, air-gap supportato. Se la lezione di Astra è che un modello di frontiera può weaponizzare le tue vulnerabilità, la risposta non è mandare la tua superficie d'attacco viva al modello di frontiera di qualcun altro per scoprirlo. Il motore offensivo lo fai girare dentro il tuo perimetro, sul tuo hardware, e nulla della tua topologia lascia l'edificio.

E poiché l'exploit deve comunque arrivare — come pagina drive-by, fetch di secondo stadio, beacon C2 — il modello di AI Traffic Analysis osserva il filo in parallelo: un modello deep-learning con quattro teste di inferenza (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) addestrato su miliardi di sequenze PCAP, in esecuzione sulla GPU dell'appliance a 2,7+ Gbit/s. Segnala il beacon di staging verso l'ASN mai visto dopo una visita del browser mentre sta accadendo, non nel digest SIEM di domani. Scrivere l'exploit costa sempre meno. La finestra per intercettarlo si sposta sulla rete.