Claude Opus 5 costruisce exploit per OpenAI: da 72 ore a repo…

Tre ricercatori hanno usato Claude Opus 5 per sviluppare una catena di exploit contro il forum Discourse di OpenAI. L'accesso alla repo interna è costato meno di

Il 25 luglio 2026 tre ricercatori di Hacktron hanno completato una catena di exploit contro l'infrastruttura di OpenAI sviluppando il payload con Claude Opus 5, il modello di Anthropic rilasciato quello stesso giorno. In meno di 72 ore sono passati dalla scoperta di un heap overflow in libheif all'apertura di una pull request nella monorepo interna openai/openai, dimostrando che le capacità offensive dell'AI non crescono in modo graduale ma per salti discreti che il calendario delle difese non riesce a precedere.

Punti chiave

Claude Opus 4.8, testato nelle settimane precedenti, era fallito nel bypassare l'ASLR; Opus 5 ha prodotto un exploit ARM64 funzionante in 3 ore e il porting x86-64/jemalloc entro la mattina del 25 luglio.
La catena ha sfruttato CVE-2026-32882 nel parser HEIF di libheif 1.19.7 su Debian 12, attivato tramite il fallback ImageMagick del forum Discourse di OpenAI.
Una misconfigurazione nell'SSO di OpenAI ha permesso ai token di autenticazione del forum di erogare accesso API completo agli account ChatGPT e Codex degli stessi utenti, senza interazione aggiuntiva.
La campagna HEIF Heist è costata meno di 3.000 dollari in token AI; OpenAI ha pagato 6.500 dollari di bounty per il solo lato SSO, con il forum RCE fuori dal perimetro del programma.

Il passaggio da Opus 4.8 a Opus 5: un muro e poi una porta

I ricercatori di Hacktron avevano iniziato a testare Claude Opus 4.8 già nelle settimane precedenti. Il modello precedente aveva raggiunto l'esecuzione di codice remoto con l'ASLR disabilitato, ma aveva "colpito un muro" nel bypassare le protezioni di randomizzazione degli indirizzi, secondo il report di Hacktron. La transizione a Opus 5, rilasciato la sera del 24 luglio, ha cambiato la prospettiva: in 3 ore il modello ha generato un exploit funzionante per l'architettura ARM64; entro le 6 del mattino del 25 luglio il payload era stato portato su x86-64 con il jemalloc allocator usato dall'istanza Discourse di OpenAI.

Il salto tecnico non è graduale. Opus 4.8 e Opus 5 separano una capacità che manca da una che funziona, senza zona intermedia. Questo schema, che i ricercatori chiamano "capability overhang", indica che i modelli di AI possono rimanere apparentemente limitati per mesi e poi superare una soglia critica in un singolo aggiornamento, rendendo obsolete le valutazioni di rischio basate sui test precedenti.

La catena tecnica: da un heap overflow al controllo di Codex

La vulnerabilità risiede in libheif 1.19.7, la libreria di parsing HEIF inclusa nell'immagine Docker di Discourse basata su Debian 12. Il commit che correggeva il difetto, 85e21ad44 con il messaggio "simplify overlay overlap area computation", era stato applicato upstream un anno prima ma non era stato documentato come fix di sicurezza né aveva ricevuto un CVE. I ricercatori hanno attivato il bug tramite il percorso di fallback ImageMagick per gli upload HEIF nel forum Discourse di OpenAI.

Da quel punto, l'RCE sul server del forum non avrebbe dovuto propagarsi all'infrastruttura principale. Ma i token OAuth generati per l'autenticazione al forum della community portavano permessi eccessivi: secondo la dichiarazione di OpenAI a SecurityWeek, essi garantivano "full API access to associated ChatGPT and Codex accounts". Per gli utenti attivi del forum — tra cui dipendenti OpenAI — questo ha significato che la compromissione del token del forum si traduceva in un takeover senza interazione dei loro account di produzione.

I ricercatori hanno dimostrato l'impatto aprendo la pull request #1186742 nella monorepo interna openai/openai attraverso l'account Codex di un dipendente, senza leggere codice sensibile. Il Wall Street Journal ha verificato indipendentemente che i ricercatori avessero effettivamente la capacità di leggere e proporre modifiche al software interno di OpenAI.

"AI is eliminating the protection of security through complexity. It is converting once-scarce hacker expertise into cheap compute."
— Hacktron AI incident report conclusion, secondo Finance BigGo

La risposta di OpenAI e il divario economico

OpenAI ha confermato la correzione del lato SSO alle 22:49:45 UTC del 25 luglio 2026, circa 14 ore dopo la segnalazione. Il portavoce ha dichiarato a SecurityWeek: "We narrowed the permissions on Community sign-in tokens and revoked affected tokens and sessions." Discourse ha corretto il difetto libheif entro due giorni e ha aggiunto il sandboxing Landlock come difesa in profondità, secondo il commit a071880.

Il bounty pagato da OpenAI per la misconfigurazione SSO è stato di 6.500 dollari. Il test del forum RCE era fuori dal perimetro del programma di bug bounty, quindi non è stato remunerato per quella componente. La campagna completa HEIF Heist, che ha incluso test su Slack, Meta, Zoom, Shopify, GitHub Enterprise e framework come Next.js, Astro e Gatsby, è costata meno di 3.000 dollari in token AI, secondo il CTO di Hacktron Mohan Pedhapati citato da Finance BigGo.

Il divario è netto: meno di 3.000 dollari di costo computazionale per costruire capacità che hanno attraversato difese di produzione con ASLR e allocatori moderni, contro 6.500 dollari di bounty per una vulnerabilità che avrebbe potuto permettere l'accesso a repository interni. Joshua Saxe, CTO di Abundant Security, ha sintetizzato: "Global software is riddled with security vulnerabilities. The reason we haven't found all of them is that until last year, only a few thousand people were truly skilled at finding vulnerabilities. Now, AI agents are democratizing this capability to people with lower technical skill levels."

Cosa sappiamo e cosa il dossier non documenta

Il dossier tecnico presenta alcuni punti non chiariti. Non emerge se attori malevoli abbiano sfruttato la stessa catena prima della divulgazione di Hacktron. Il numero esatto di account dipendente potenzialmente esposti dalla misconfigurazione SSO non è stato reso pubblico. Non è noto se le revisioni interne di OpenAI abbiano trovato tracce di sfruttamento precedente oltre alla PR #1186742.

La metodologia specifica con cui Opus 5 ha bypassato l'ASLR non è stata divulgata per motivi di responsible disclosure. Il punteggio CVSS ufficiale da NVD o dal CNA Discourse per CVE-2026-32882 non è disponibile; Red Hat ha pubblicato una valutazione preliminare 7.1 HIGH con vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:H, che tuttavia non include l'esecuzione di codice nella sua analisi preliminare. Non è documentato se Anthropic abbia modificato le barriere di sicurezza di Opus 5 a seguito dell'incidente.

Cosa fare adesso

Verificare i permessi dei token OAuth nei flussi SSO perimetrali: i token emessi per servizi di community o forum devono essere auditati per scope minimi, specialmente quando collegati ad account di produzione con accesso API.
Rivedere le dipendenze di parsing multimediale nei deployment esposti: librerie come libheif, ImageMagick e i loro fallback costituiscono superficie di attacco per file format-specific; il commit 85e21ad44 dimostra che fix esistenti possono rimanere invisibili senza CVE.
Ricalibrare i modelli di bounty sul potenziale di escalazione: quando la compromissione di un servizio perimetrale si traduce in accesso a repository interni, il framework di valutazione del bounty deve riflettere l'impact reale della catena, non solo la falla d'ingresso.
Testare i modelli AI contro i propri asset prima che lo facciano altri: la discontinuità tra Opus 4.8 e Opus 5 indica che i cicli di valutazione delle capacità offensive devono essere sincronizzati con i rilasci dei modelli, non con i calendari di audit tradizionali.

Perché questo cambia il perimetro della sicurezza

L'incidente non è una compromissione malevola né una dimostrazione di AI autonoma. È una segnalazione di bounty condivisa pubblicamente che rivela una dinamica più profonda: la complessità che finora ha protetto il software globale — la scarsità di expertise nel bypassare ASLR, nel calcolare offset di heap, nel costruire chain RPE — sta diventando un bene computazionale. Il risultato è che il tempo di sviluppo di un exploit da settimane a ore si traduce in una velocità d'attacco che i cicli di patch e i programmi di bounty non sono strutturati per assorbire.

Il problema federato dell'identità amplifica l'effetto. Quando un token di forum eroga accesso API completo a ChatGPT e Codex, il confine tra superficie di attacco perimetrale e infrastruttura critica si dissolve. I servizi di community, i forum, le istanze di supporto diventano pivot obbligati non per la loro sensibilità intrinseca, ma per la trust relationship che conservano con i sistemi principali. La lezione non è che OpenAI è stato "hackerato": è che la configurazione della fiducia tra servizi federati richiede una ridefinizione quando l'attaccante può costruire l'exploit in una notte.

FAQ

Il modello Claude ha agito in modo autonomo?

No. I ricercatori descrivono l'operazione come assistita dall'AI, non autonoma: la "skilled human guidance" è rimasta essenziale per l'orchestrazione e il targeting. Claude Opus 5 è stato usato come strumento di generazione del payload, non come agente indipendente.

I ricercatori hanno rubato codice sorgente o pesi di modello?

No. Secondo il report di Hacktron, i ricercatori si sono fermati alla apertura di una pull request innocua (#1186742) e non hanno letto codice sensibile. Non è documentata alcuna esfiltrazione di dati.

La vulnerabilità era nel modello AI di OpenAI?

No. Il difetto era in libheif 1.19.7, una dipendenza di terze parti nel forum Discourse di OpenAI, combinato con una misconfigurazione lato SSO di OpenAI. I modelli AI di OpenAI non sono stati compromessi né manipolati.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Fonti e riferimenti

Ricevi DeafLetter