Un AI di Anthropic ha aiutato a bucare account e codice interno di OpenAI

La notizia, nella sua forma più elementare, ha qualcosa di paradossale: un modello di intelligenza artificiale progettato per scrivere codice — Claude, sviluppato da Anthropic — è diventato lo strumento con cui un piccolo gruppo di ricercatori ha compromesso l'account ChatGPT di un dipendente OpenAI, arrivando poi a porzioni riservate del codice sorgente interno dell'azienda. Tutto questo, però, non è avvenuto nell'ombra: il lavoro è stato svolto nell'ambito di una responsible disclosure, cioè una pratica in cui chi trova una vulnerabilità la segnala all'azienda colpita anziché sfruttarla illecitamente, ed è stato compensato attraverso un programma di bug bounty. Proprio questo aspetto rende il caso più interessante del solito: offre uno spaccato concreto su come cambiano le dinamiche di sicurezza quando strumenti potenti di scrittura e analisi del codice sono disponibili su richiesta, e quanto siano fragili — nella pratica — i confini tra servizi considerati secondari e sistemi centrali.

Una falla nelle immagini, una porta aperta

Il punto di partenza tecnico è un forum online gestito con Discourse — una piattaforma open source molto diffusa per community e discussioni — usato dalla community di OpenAI. Il team di ricercatori, che opera sotto il nome Hacktron AI, ha sfruttato una vulnerabilità nella gestione delle immagini caricate dagli utenti: un dettaglio che può sembrare banale ma non lo è. Ogni volta che si carica un'immagine su una piattaforma web, il server deve elaborarla — convertirla, ridimensionarla, indicizzarla — usando librerie software specializzate, alcune delle quali hanno una storia travagliata dal punto di vista della sicurezza.

In questo caso, il punto d'ingresso sarebbe stato un difetto in libheif, una libreria che gestisce formati di immagine moderni come HEIF e AVIF. Sfruttando questa falla attraverso strumenti comuni nella catena di elaborazione delle immagini, i ricercatori sarebbero riusciti a ottenere l'esecuzione di codice da remoto: in pratica, far girare istruzioni proprie sul server della vittima semplicemente caricando un file immagine manipolato. Discourse ha pubblicato un avviso di sicurezza datato 28 luglio 2026, assegnando alla vulnerabilità un punteggio CVSS di 8,8 su 10 — soglia che nel settore corrisponde a gravità alta. La correzione sarebbe arrivata in due giorni, con l'aggiunta di un livello di isolamento (sandboxing) per tutta la parte di elaborazione delle immagini: un intervento che va oltre la singola toppa e riconosce che questo tipo di pipeline è strutturalmente esposto.

Dal forum al codice segreto di OpenAI

Fin qui si potrebbe liquidare la vicenda come un problema di software di terze parti, interessante ma circoscritto. Il salto che trasforma questo episodio in un caso da studiare avviene subito dopo: dalla compromissione del forum, i ricercatori avrebbero ottenuto dei token di autenticazione — credenziali digitali temporanee che certificano l'identità di un utente — e almeno parte di questi token sarebbe risultata valida anche per accedere ad altri servizi di OpenAI, inclusi account di dipendenti su ChatGPT e, secondo alcune ricostruzioni, su Codex, il sistema di generazione automatica di codice dell'azienda. Da lì, il passo verso un repository privato su GitHub contenente materiale tecnico riservato.

È qui che vale la pena fermarsi e chiedersi dove abbia davvero ceduto il perimetro. Raccontare questa storia come «Claude ha generato un exploit, quindi l'AI è pericolosa» oppure come «c'era un bug in Discourse, basta aggiornare» significa ridurre troppo la complessità. Un incidente che parte da un forum community e arriva a token riutilizzabili su sistemi centrali racconta un problema di architettura: come vengono gestite le identità digitali, come sono separati i servizi tra loro, quanto è ampio il blast radius — cioè fino a dove si propaga il danno — di un singolo punto di accesso compromesso.

Un token nato per un forum non dovrebbe aprire le porte ai sistemi interni di un'azienda

La sicurezza moderna non si costruisce con muri impermeabili, ma con frizioni e segmentazioni: ogni servizio dovrebbe accettare solo credenziali emesse per quel servizio, con permessi limitati al minimo necessario. Se un token pensato per autenticare un utente su un forum può essere speso anche altrove — o può innescare un flusso di accesso a sistemi ad alto valore — il problema non si risolve con una patch. Si risolve riprogettando come vengono emessi, validati e isolati i permessi. Nel lessico della sicurezza, concetti come audience restriction (limitare a chi un token è accettato), token binding (legare il token a un contesto specifico) e least privilege (concedere sempre il minimo indispensabile) non sono sottigliezze accademiche: sono l'unico modo per evitare che un incidente periferico diventi una compromissione strategica.

Claude come acceleratore, non come grimaldello

In questo quadro entra il ruolo di Claude. I ricercatori non avrebbero usato l'AI come una bacchetta magica capace di violare qualunque sistema, ma come un acceleratore: uno strumento che riduce drasticamente il tempo tra l'intuizione — «qui c'è qualcosa di anomalo» — e una catena d'attacco funzionante. La ricostruzione di SecurityWeek descrive più tentativi e un passaggio da Claude Opus 4.8 a Opus 5, con l'aggiornamento che avrebbe sbloccato la capacità di superare un ostacolo emerso nel primo tentativo. Se la timeline complessiva è davvero nell'ordine delle 72 ore, come riportato da più fonti, il dato va letto per ciò che rappresenta: la compressione del ciclo «scopro → sviluppo → rendo affidabile».

L'annuncio di Claude Opus 5 è del 24 luglio 2026: nelle note ufficiali, Anthropic posiziona il modello come molto efficace su coding e lavoro intellettuale complesso, pur dichiarando che resta dietro ad altri modelli specializzati su compiti di cybersecurity. Parallelamente, Anthropic ha dichiarato di voler consentire l'analisi e l'individuazione di vulnerabilità nel codice sorgente, ma di bloccare la generazione diretta di exploit e le attività di penetration testing. È un confine di regole interne che, nella pratica, può farsi poroso quando chi lavora non chiede esplicitamente «scrivimi un exploit», ma costruisce la soluzione per frammenti: analisi di un crash, trasformazione di un input, adattamento del payload, debugging iterativo. Non serve un comando esplicito se si può ottenere lo stesso risultato con una sequenza di richieste apparentemente innocue — è l'equivalente di ciò che è già avvenuto in altri ambiti dell'automazione.

Il caso Hacktron AI diventa così un test di stress per i guardrail dei modelli: non perché dimostri che «i modelli scrivono exploit», ma perché mostra quanto sia difficile distinguere in modo affidabile tra un flusso di lavoro difensivo (capire e correggere un bug) e uno offensivo (capire e sfruttare un bug), quando entrambi passano dalle stesse capacità generiche di ragionamento e scrittura del codice.

Bug bounty e incentivi sotto pressione

OpenAI ha scelto di investire in modo significativo nella strutturazione dei propri programmi di segnalazione. La sua Coordinated Vulnerability Disclosure Policy è aggiornata al 25 marzo 2026 e definisce obiettivi e perimetri del bug bounty. Nello stesso giorno OpenAI ha lanciato anche un Safety Bug Bounty, pensato per segnalare rischi di abuso e problemi di sicurezza che non rientrano nelle vulnerabilità tecniche classiche — un segnale di come la frontiera si stia spostando dal bug tradizionale alla capacità di un sistema di essere usato in modi imprevisti.

Sul fronte degli incentivi economici, VentureBeat riporta un pagamento di 6.500 dollari ai ricercatori, con una precisazione rilevante: testare direttamente il forum Discourse sarebbe stato fuori dallo scope del bug bounty OpenAI, mentre la parte della catena che riguardava direttamente i sistemi OpenAI sarebbe stata quella premiata. Questa distinzione è comune nelle grandi aziende, ma diventa problematica quando i servizi «di terze parti» sono integrati con l'identità e i flussi di accesso interni: il confine tra «nostro» e «esterno» è meno netto di quanto appaia nei regolamenti.

L'AI abbassa la barriera tecnica e aumenta il volume di segnalazioni, buone e cattive insieme

A fine luglio 2026, GitHub ha annunciato una ristrutturazione del proprio programma di bug bounty, citando un'ondata di segnalazioni a bassa qualità, spesso generate con strumenti AI. Il nuovo schema prevede una separazione più netta tra un livello pubblico e uno su invito, con compensi fissi per gravità e un livello riservato più remunerativo. Non è la stessa storia dell'episodio OpenAI, ma appartiene allo stesso paesaggio: più AI in circolazione significa più capacità sia per trovare falle serie sia per produrre rumore, e i programmi devono adattarsi per non collassare sotto il volume.

Il contesto europeo: quando la regola incontra la realtà

C'è una cornice normativa che, dal punto di vista europeo, aggiunge un livello di lettura. Il CRA dell'Unione Europea ha attivato — dall'11 settembre 2026 — obblighi di segnalazione per vulnerabilità attivamente sfruttate e incidenti gravi che impattano la sicurezza di prodotti digitali, con un canale di notifica verso i CSIRT nazionali e una piattaforma centralizzata a livello UE. Non è detto che un caso come quello del forum Discourse rientri automaticamente nel perimetro del CRA per ogni attore coinvolto, ma la direzione è chiara: l'Europa sta costruendo un ecosistema in cui la gestione delle vulnerabilità non è solo buona pratica, ma adempimento tracciabile e tempestivo.

Parallelamente, nel settore finanziario il DORA è applicabile dal 17 gennaio 2025 e sta normalizzando obblighi di incident reporting e gestione del rischio informatico in modo armonizzato tra i Paesi membri. In questo contesto regolatorio, l'idea che un servizio «non core» possa diventare la porta d'ingresso verso token e identità aziendali non è solo un problema tecnico: è esattamente il tipo di dipendenza da terze parti che le nuove normative chiedono di mappare, monitorare e presidiare.

Cosa cambia per aziende e utenti

La lezione più utile per chi usa quotidianamente piattaforme come ChatGPT non è «ti ruberanno l'account con un exploit AI». La vicenda riguarda un account di un dipendente e una catena legata a integrazioni e token, non un attacco di massa agli utenti comuni. Il punto pratico è che l'asticella della sicurezza deve salire su due fronti distinti.

Il primo riguarda le aziende: segmentare davvero identità e sessioni tra servizi diversi. Significa evitare che un token emesso per un forum possa essere speso altrove, e separare in modo più aggressivo gli account dei dipendenti dagli ambienti di sviluppo. È un costo operativo reale — più passaggi di autenticazione, più complessità di gestione — ma è anche la differenza tra un incidente contenuto e uno che diventa una storia pubblica imbarazzante.

Il secondo fronte riguarda i produttori di modelli: la capacità di coding generalista rende difficile bloccare i comportamenti offensivi senza bloccare anche quelli difensivi legittimi. Anthropic prova a gestire questa tensione con guardrail, programmi di accesso controllato per contesti di sicurezza informatica e strumenti orientati alla difesa. Il caso mostra però che il rischio non vive solo nell'output finale, ma nel processo: la capacità di portare un tentativo fallito a un tentativo riuscito, in poche iterazioni, cambiando modello o impostazione, è il vero cambiamento strutturale.

Quando si parla di «AI che abbassa la barriera d'ingresso», spesso si intende un concetto astratto. Qui la barriera è visibile: ore o giorni risparmiati su un compito che, fino a poco tempo fa, richiedeva una combinazione rara di competenze e tempo. Le aziende possono rispondere con aggiornamenti più rapidi e programmi di bug bounty più maturi. Ma la variabile che resta aperta è un'altra: quanto velocemente i sistemi di identità, i confini tra servizi e la segmentazione interna riusciranno a evolversi allo stesso ritmo con cui evolvono i modelli che scrivono, leggono e trasformano codice.