Il primo zero-day sviluppato con l'ausilio di un modello AI aggira la 2FA: il
Il report GTIG dell'11 maggio 2026 rivela il primo zero-day sviluppato con l'ausilio di un modello AI: codice con CVSS allucinato e 2FA bypassata su un tool op…
Contenuto
Google Threat Intelligence Group ha pubblicato l'11 maggio 2026 il report AI Threat Tracker, rivelando la prima campagna interrotta in cui un gruppo cybercriminale ha fatto affidamento su un modello AI per supportare la scoperta e la weaponizzazione di una zero-day.
L'exploit, uno script Python in grado di bypassare la 2FA su un tool open-source di amministrazione web-based, è stato bloccato prima del mass exploitation.
La novità non è la potenza del codice, ma la sua firma: struttura didattica, docstring educative e un punteggio CVSS inventato, elementi che tradiscono l'uso di un modello AI come supporto e dimostrano che la corsa offensiva all'AI è già iniziata.
- GTIG ha individuato per la prima volta uno zero-day weaponizzato con l'ausilio di un LLM, pubblicando il report AI Threat Tracker l'11 maggio 2026.
- L'exploit è uno script Python che bypassa la 2FA su un tool open-source sfruttando un logic flaw di autorizzazione con trust assumption hardcoded inefficace, non una memory corruption.
- Google esclude l'uso di Gemini e afferma di avere alta confidenza che l'attore abbia usato un modello AI come supporto, basandosi sulle impronte stilistiche del codice.
- La campagna è stata interrotta prima del mass exploitation e Google ha collaborato con il vendor per chiudere la vulnerabilità, ma il nome del gruppo e del tool non sono stati divulgati.
Come si riconosce un exploit scritto da un LLM
L'analisi del payload condotta da GTIG ha individuato anomalie stilistiche che raramente compaiono in codice sviluppato manualmente da threat actor tradizionali. Il file Python presentava docstring eccessivamente didattiche, help menus dettagliati e una classe ANSI color C formattata secondo uno stile textbook Pythonic, tipico dei dataset di training dei grandi modelli linguistici. Questi elementi, di per sé innocui, costituiscono in ambito offensivo un'incongruenza: il codice malware è solitamente essenziale, offuscato e privo di commenti educativi.
La firma più evidente era tuttavia un punteggio CVSS autoassegnato e allucinato, inserito direttamente nel sorgente come se l'autore avesse richiesto al modello una valutazione del rischio. Il valore non corrispondeva a calcoli standard e tradisce una generazione assistita priva di verifica umana rigorosa. Per i difensori, questi pattern diventano indicatori di compromissione: un payload troppo pulito e pedagogico può segnalare origine AI più efficacemente di una firma comportamentale.
"There’s a misconception that the AI vulnerability race is imminent. The reality is that it’s already begun. For every zero-day we can trace back to AI, there are probably many more out there" — Chief analyst at GTIG
Il meccanismo del bypass: logic flaw contro trust assumption hardcoded
Tecnicamente, l'exploit non sfrutta una memory corruption o un bug di input validation, bensì un logic flaw di autorizzazione. Il tool open-source target presentava una trust assumption hardcoded inefficace: una credenza implicita dello sviluppatore che certi flussi fossero protetti semplicemente perché collocati dietro autenticazione. Con credenziali valide in possesso dell'attaccante, lo script Python ha correlato il 2FA enforcement logic con le eccezioni hardcoded, aggirando il controllo.
Secondo i ricercatori di GTIG, il punto critico è la capacità del modello di reasoning contestuale: "Though frontier LLMs struggle to navigate complex enterprise authorization logic, they have an increasing ability to perform contextual reasoning, effectively reading the developer’s intent to correlate the 2FA enforcement logic with the contradictions of its hardcoded exceptions", come si legge nel report.
Questo approccio cambia la superficie di attacco. I logic flaw dormienti, invisibili agli scanner SAST e DAST tradizionali, diventano accessibili a modelli che leggono il codice sorgente come testo naturale e ne svelano le contraddizioni. Per i vendor, la conseguenza è chiara: le assumption hardcoded richiedono ora una revisione dedicata, perché un LLM può scovarle e weaponizzarle in tempi molto più rapidi di un umano.
Perché Google esclude Gemini ma conferma l'uso di un AI model
Nel report, Google afferma esplicitamente di non ritenere che il proprio modello Gemini sia stato impiegato nella fase di discovery o weaponizzazione. Al contempo, la struttura e il contenuto del codice forniscono alta confidenza che l'attore abbia fatto affidamento su un modello AI esterno. "Although we do not believe Gemini was used, based on the structure and content of these exploits, we have high confidence that the actor likely leveraged an AI model to support the discovery and weaponization of this vulnerability", si legge nel documento.
L'esclusione di Gemini non è un dettaglio di marketing: sottolinea che la minaccia non dipende da un singolo provider o da un modello proprietario. L'attore ha potuto usare strumenti open source, API commerciali di terzi o modelli self-hosted. Il dato ignoto resta il grado di supervisione umana: le fonti non chiariscono se un operatore abbia semplicemente incollato output AI o abbia orchestrato l'intero flusso, anche se la formulazione "likely leveraged" suggerisce un supporto attivo piuttosto che una creazione completamente autonoma.
Cosa fare adesso
Per i vendor di tool open-source web-based, la prima azione è eliminare le trust assumption hardcoded dalle logiche di autorizzazione. Questi flaw non vengono rilevati da scanner SAST o DAST tradizionali, e un LLM con credenziali valide può sfruttarli aggirando il 2FA enforcement in tempi molto brevi. La review manuale dei flussi di autenticazione multilivello diventa un passaggio obbligatorio, non opzionale.
I team di threat intelligence devono aggiornare le firme di detection includendo indicatori stilistici AI: docstring eccessivamente didattiche, punteggi CVSS autoassegnati e classi ANSI in formato textbook sono tre anomalie in payload offensivi. Un codice troppo pulito può segnalare generazione assistita prima della distribuzione. Red team e ricercatori devono inoltre integrare LLM nei cicli di security testing per anticipare gli attaccanti, verificando se un modello riesce a leggere l'intento dello sviluppatore e a trovare inconsistenze hardcoded nelle proprie codebase.
La linea del fronte si sposta dai bug di memoria ai logic flaw
La scoperta di GTIG sposta l'attenzione difensiva da una domanda consolidata a una nuova. Non più se il codice contiene un buffer overflow, ma se la sua logica di autorizzazione nasconde un'intenzione leggibile da un modello meglio di quanto non lo sia da un auditor umano. Gli LLM non dimostrano ancora padronanza nella costruzione di exploit di corruzione memoria sofisticati, ma mostrano abilità crescente nel reasoning contestuale su logiche di business. Per le aziende che dipendono da tool web-based open-source, questo allarga il perimetro di attacco alle applicazioni considerate stabili proprio perché prive di bug classici.
Il caso GTIG non amplifica la narrativa dell'AI onnipotente, ma ne smonta l'aura: il codice è stato intercettato perché chi ha usato l'AI come supporto ha lasciato impronte troppo evidenti. Il segnale concreto è che, per la prima volta, un modello linguistico ha assistito attivamente il ciclo tra scoperta e weaponizzazione, abbassando la soglia per attori che fino a ieri non avrebbero avuto risorse per trovare zero-day. Difendere il perimetro oggi significa guardare non solo al codice vulnerabile, ma al codice generato per attaccarlo.
Domande e risposte
Lo zero-day ha colpito vittime reali?
No. Google ha collaborato con il vendor per chiudere la vulnerabilità e interrompere la campagna prima che l'exploit potesse essere sfruttato su larga scala. L'attacco richiedeva inoltre credenziali valide dell'utente per funzionare, limitandone ulteriormente la superficie di compromissione diffusa.
Perché gli scanner di sicurezza non hanno rilevato il flaw?
Perché si tratta di un logic flaw di autorizzazione, non di una vulnerabilità di tipo memory corruption o input validation. Le trust assumption hardcoded non emergono dalle analisi statiche o dinamiche tradizionali e richiedono una revisione manuale della logica di business.
Gli analisti hanno identificato il modello AI usato?
No. Google ha escluso con alta confidenza l'uso di Gemini, ma il modello specifico resta ignoto. Il report GTIG non ha reso pubblici né il nome del gruppo cybercriminale né quello del tool open-source target, entrambi omessi per motivi di sicurezza.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.