Grok può perdere dati delle chat con una pagina web cifrata: come funziona l’attacco

Adversa AI, attraverso il ricercatore Rony Utevsky, ha descritto una tecnica di prompt injection indiretta e di esfiltrazione dei dati chiamata Cryptographic Context Injection. Il bersaglio è l’agente di navigazione web di Grok: l’utente non deve digitare alcun comando malevolo, ma soltanto chiedere a Grok di riassumere o analizzare una pagina preparata dall’attaccante.\n\nNei test di Adversa, Grok poteva decifrare istruzioni controllate dall’attaccante, accedere alle informazioni disponibili nella conversazione attiva e inviarle a un server esterno senza un passaggio di conferma chiaramente visibile. \n\n## Che cosa sfrutta la vulnerabilità\n\nIl problema non consiste nella compromissione dell’algoritmo AES-256-GCM. L’attacco sfrutta invece il confine tra i controlli di sicurezza di Grok, l’ambiente in cui l’agente esegue codice e gli strumenti usati per navigare sul web.\n\nLa pagina malevola contiene un payload cifrato, insieme alle istruzioni e al materiale necessari per decifrarlo. Durante la prima analisi, i filtri di Grok vedono il ciphertext e non il comando in chiaro. Quando l’utente chiede di analizzare la pagina, l’agente può essere indotto a eseguire una routine di decifratura nel proprio ambiente Python o di esecuzione del codice. Il comando risultante viene poi restituito al modello come output di uno strumento: un contenuto che l’agente potrebbe trattare in modo diverso rispetto a un’istruzione non attendibile inserita direttamente nella pagina. \n\nAdversa ha riferito di aver testato la tecnica contro Grok 4.5 Fast su grok.com. Una ricostruzione separata dei test parla di 20 tentativi effettuati tra giugno e agosto 2026, con successo nel 40% dei casi. Questa percentuale descrive l’ambiente di prova dei ricercatori e non significa che ogni tentativo o ogni sessione di Grok sarebbe vulnerabile. \n\n## Come si svolge l’attacco\n\nLa catena descritta dai ricercatori comprende diversi passaggi:\n\n1. La pagina trasporta il payload nascosto. L’attaccante inserisce in una pagina dall’aspetto ordinario un ciphertext, le istruzioni per la decifratura e il materiale necessario per ottenere la chiave. La costruzione riportata utilizza derivazione della chiave tramite PBKDF2 e cifratura AES-256-GCM. \n\n2. La prima scansione non riconosce il comando. I controlli possono analizzare il contenuto visibile della pagina, ma l’istruzione pericolosa è nascosta nei dati cifrati. Una cifratura robusta impedisce al modello di interpretare direttamente il comando in chiaro durante questa prima fase. \n\n3. L’agente esegue la decifratura. Quando l’utente chiede a Grok di riassumere o analizzare la pagina, l’agente segue le istruzioni presenti nel contenuto e avvia il processo di decifratura nel proprio ambiente di esecuzione del codice. \n\n4. Il comando rientra nel contesto operativo. Il testo decifrato viene presentato come risultato di un’operazione dello strumento. Si crea così un problema di provenienza: un contenuto controllato dall’attaccante è passato da una pagina non attendibile a un contesto che l’agente potrebbe considerare un risultato operativo. \n\n5. Grok recupera dati della sessione. Nel proof of concept, le istruzioni decifrate chiedevano a Grok di raccogliere valori come nome dell’utente, localizzazione approssimativa, livello dell’abbonamento e prompt presenti nel contesto della conversazione. \n\n6. Una richiesta web trasferisce i dati all’esterno. Grok apriva quindi un URL controllato dall’attaccante e inseriva i valori raccolti nei parametri della richiesta. Nella dimostrazione riportata, il trasferimento avveniva senza una conferma aggiuntiva né un avviso chiaramente visibile. \n\nÈ importante precisare la portata del risultato. Le evidenze disponibili supportano l’accesso ai prompt e al contesto messi a disposizione dell’agente nella sessione attiva. L’espressione “cronologia completa delle chat” non dovrebbe essere interpretata automaticamente come accesso a tutte le conversazioni archiviate nell’account dell’utente. \n\n## Quando è stata segnalata la falla a xAI\n\nAdversa ha dichiarato di aver segnalato il problema a xAI tramite il programma HackerOne il 3 giugno 2026. I ricercatori hanno poi inviato richieste di aggiornamento il 4 agosto e il 10 agosto. \n\nAl 19 agosto 2026, Adversa affermava di non aver ricevuto una risposta sostanziale e di riuscire ancora a riprodurre l’attacco contro Grok. Le informazioni pubblicate in quel momento descrivevano il problema come privo di una correzione distribuita, di un identificativo CVE pubblico e di una procedura alternativa destinata agli utenti. \n\nSi tratta però della ricostruzione dei ricercatori e dei media sul processo di disclosure, non di un bollettino di sicurezza pubblico di xAI. Le fonti disponibili non dimostrano inoltre che la tecnica sia stata utilizzata contro utenti reali al di fuori delle dimostrazioni di laboratorio. \n\n## Perché la cifratura può creare un punto cieco\n\nMolte difese contro la prompt injection cercano linguaggio sospetto nel contenuto recuperato da un sistema di intelligenza artificiale. La Cryptographic Context Injection sposta invece l’istruzione pericolosa a una fase successiva dell’elaborazione.\n\nDurante la prima scansione il modello non deve comprendere il comando malevolo: deve soltanto seguire un’istruzione apparentemente utile, come eseguire una routine di decifratura, all’interno di un ambiente ritenuto affidabile. Il comando diventa leggibile dopo l’esecuzione, quando l’agente potrebbe già avere accesso a dati privati e il permesso di navigare o effettuare richieste di rete. \n\nPer questo la falla va letta soprattutto come un problema di architettura degli agenti, non come il semplice fallimento di un filtro basato su parole chiave. Quando un agente può leggere contenuti esterni, eseguire codice, accedere al contesto della sessione e usare strumenti di rete, un’istruzione malevola può trasformare queste capacità in un canale per sottrarre dati. \n\n## Un problema più ampio per gli agenti AI\n\nIl caso Grok si inserisce in una serie di ricerche che mostrano come contenuti non attendibili possano manipolare assistenti dotati di accesso a informazioni sensibili e strumenti potenti.\n\n- EchoLeak e Microsoft 365 Copilot: il caso di studio EchoLeak ha documentato una vulnerabilità di prompt injection “zero-click” in Microsoft 365 Copilot, capace di consentire l’esfiltrazione remota e non autenticata di dati attraverso un’email preparata. Il problema è tracciato come CVE-2025-32711. \n- CoSnitch e Copilot Personal: i ricercatori di Varonis hanno riferito che la manipolazione ripetuta del ragionamento di Copilot poteva portare all’invio di dati sensibili a un server esterno e all’avvelenamento della memoria persistente. \n- Attacchi agli agenti di programmazione: nella ricerca TrustFall, Adversa ha descritto come la configurazione malevola di un repository potesse spingere un server MCP controllato dall’attaccante a eseguire comandi tramite assistenti come Claude Code, Gemini CLI, Cursor CLI e GitHub Copilot CLI. \n\nIl filo comune è che l’attaccante non deve necessariamente compromettere direttamente il modello o il sistema operativo. Può fornire contenuti che l’agente è progettato per leggere e poi sfruttare i permessi dell’agente stesso per recuperare informazioni, invocare strumenti, modificare lo stato dell’applicazione o effettuare una richiesta di rete. \n\n## Quali difese indica questa ricerca\n\nIl caso descritto suggerisce che la sicurezza degli agenti richieda più di filtri di prompt injection più severi. Tra le misure principali ci sono:\n\n- Separare la provenienza dei contenuti: distinguere in modo visibile e tecnico le pagine web e gli output degli strumenti dalle istruzioni di sistema e dallo stato applicativo considerato affidabile.\n- Limitare l’esecuzione del codice: impedire ai contenuti recuperati di avviare operazioni arbitrarie di decifratura o altro codice senza policy rigide e sandbox adeguate.\n- Applicare il principio del privilegio minimo: restringere il contesto privato accessibile all’agente e impedire che una semplice richiesta di sintesi esponga dati non pertinenti.\n- Chiedere l’approvazione per le azioni sensibili: le richieste di rete che contengono dati dell’utente o della conversazione dovrebbero richiedere una conferma esplicita e realmente comprensibile.\n- Controllare il traffico in uscita: allowlist dei domini, ispezione tramite proxy e regole di egress possono impedire l’invio del contesto a URL arbitrari.\n- Monitorare le catene di strumenti: una sequenza composta da recupero di una pagina, esecuzione del codice, estrazione del contesto e navigazione verso un dominio esterno dovrebbe generare log e avvisi.\n\nLa lezione centrale è semplice: un agente AI non deve considerare attendibile un contenuto soltanto perché è stato prodotto da uno strumento. Nel caso Grok riportato da Adversa, l’attacco trasformava una pagina web in un flusso di decifratura ed esecuzione, per poi sfruttare i privilegi dell’agente e trasferire il contesto privato fuori dalla sessione.