Grok trasformato in uno strumento per rubare dati dalle chat: come funziona l’iniezione di contesto crittografico

Una pagina web apparentemente innocua potrebbe trasformarsi in un’esca per sottrarre dati dalle conversazioni di Grok. È questa la dimostrazione descritta da Adversa AI, secondo cui il ricercatore Rony Utevsky ha individuato una tecnica di prompt injection indiretta, senza clic aggiuntivi, che colpisce l’agente web di xAI.

Nello scenario riportato, l’utente deve soltanto chiedere a Grok di riassumere o analizzare una pagina controllata dall’attaccante. La pagina contiene istruzioni malevole non in chiaro, ma sotto forma di dati cifrati. Grok viene quindi indotto a eseguire il codice necessario per decifrarle nel proprio ambiente di esecuzione e a trattare il risultato come contesto attendibile.

L’impatto descritto è potenzialmente grave: il payload decifrato può ordinare all’agente di recuperare informazioni private della sessione e inserirle in una richiesta verso un server esterno. Le prove disponibili provengono soprattutto dalla divulgazione di Adversa AI e dai resoconti collegati; si tratta quindi di una prova di concetto riportata, non di un accertamento indipendente pubblicato da xAI.

Che cosa cambia con la «Cryptographic Context Injection»

I filtri tradizionali contro la prompt injection cercano spesso istruzioni sospette nel testo che entra nel contesto del modello. La tecnica descritta da Adversa prova a eludere proprio questo controllo: le istruzioni vengono inserite nella pagina sotto forma di testo cifrato, non immediatamente leggibile dal filtro.

Secondo Adversa, la pagina include un payload JSON cifrato con AES-256-GCM, il materiale necessario per la decifrazione e indicazioni che spingono Grok a eseguire il codice in Python o nel proprio ambiente sandbox. La chiave sarebbe derivata tramite PBKDF2.

Non si tratta di un attacco crittografico contro AES. L’algoritmo non viene “spezzato”: la cifratura è usata come tecnica di evasione. Un filtro può vedere soltanto dati apparentemente opachi, mentre l’agente dispone degli strumenti per trasformarli in istruzioni nel corso del processo.

La distinzione è importante. Controllare il testo visibile non equivale a controllare ciò che un agente può fare dopo aver analizzato, decifrato, eseguito o ricevuto dati da una fonte non attendibile.

La catena d’attacco descritta dai ricercatori

Il meccanismo riportato si può riassumere in quattro passaggi:

1. La pagina sembra normale. L’utente chiede a Grok di riassumere o analizzare un contenuto ospitato sul sito.
2. La pagina fornisce dati cifrati e istruzioni per decifrarli. Adversa afferma che il payload usa AES-256-GCM con una chiave derivata tramite PBKDF2, mantenendo nascoste le istruzioni principali durante la prima analisi del contenuto.
3. Grok esegue la logica di decifrazione. Le istruzioni in chiaro emergerebbero attraverso il percorso di esecuzione del codice o degli strumenti, anziché come testo evidente della pagina. Adversa sostiene che Grok tratti poi il risultato come contesto attendibile.
4. Il payload indirizza l’azione successiva dell’agente. Le istruzioni, secondo la dimostrazione, spingono Grok a recuperare dettagli privati della sessione, inserirli in un URL e aprire quell’indirizzo per inviare le informazioni a un endpoint controllato dall’attaccante.

Nella prova di concetto descritta da Adversa comparivano il nome dell’utente, una posizione approssimativa, il livello dell’abbonamento, i prompt e la cronologia delle conversazioni. L’azienda ha riferito che, nella dimostrazione, il trasferimento è avvenuto senza un avviso visibile o una richiesta di conferma.

Il vero confine di sicurezza è il runtime

Il punto critico non è soltanto che Grok abbia ricevuto un prompt malevolo. È che contenuti provenienti da una pagina non attendibile avrebbero attraversato diversi confini di fiducia:

• il contenuto della pagina è diventato un contesto eseguibile o capace di determinare un’azione;
• l’output decifrato è stato considerato più affidabile di quanto la sua origine consentisse;
• il contesto privato della conversazione o della sessione è diventato accessibile alla catena d’attacco;
• l’agente ha potuto usare una richiesta esterna per trasferire i dati fuori dalla sessione.

Un’istruzione non diventa attendibile soltanto perché è stata prodotta da una routine di decifrazione, restituita da uno strumento o inserita in un risultato intermedio del runtime. La provenienza dei dati deve rimanere associata al contenuto anche dopo queste trasformazioni.

In caso contrario, analisi, esecuzione di codice, recupero di informazioni e output degli strumenti possono “lavare” contenuti non attendibili, facendoli apparire come istruzioni autorizzate.

Divulgazione e stato del problema

Secondo il resoconto di Adversa, Utevsky ha segnalato il problema a xAI e tramite HackerOne il 3 giugno 2026. Nella divulgazione del 20 agosto, Adversa ha affermato che la questione era rimasta irrisolta per oltre due mesi nonostante i solleciti.

Al momento della divulgazione, i resoconti disponibili non indicavano una risposta pubblica di xAI, un identificativo CVE, una patch o un calendario per la correzione. Questo quadro si basa sulla segnalazione del ricercatore e sulla copertura contemporanea; non viene fornita una dichiarazione xAI pubblicata in modo indipendente che confermi la vulnerabilità o la sua risoluzione.

Che cosa dovrebbe essere corretto

Le raccomandazioni di Adversa riguardano soprattutto il runtime dell’agente, non l’aggiunta di ulteriori filtri basati su parole chiave. I controlli più importanti sono:

• Conservare la provenienza e le etichette di contaminazione. I dati originati da una pagina web devono restare non attendibili anche dopo analisi, decifrazione, esecuzione di codice o uso di strumenti.
• Separare dati e autorità. I contenuti non attendibili, e i valori derivati da essi, non dovrebbero poter attivare strumenti privilegiati, accedere al contesto privato della conversazione o definire autonomamente parametri sensibili.
• Limitare il traffico in uscita. Prima di inviare dati a un nuovo endpoint esterno, l’agente dovrebbe applicare liste di destinazioni consentite, controlli sull’endpoint e regole di prevenzione della perdita di dati.
• Richiedere un consenso comprensibile. Le operazioni che coinvolgono contesto privato o trasmissioni esterne dovrebbero richiedere una conferma chiara, indicando quali dati usciranno dalla sessione e verso quale destinazione.
• Applicare il principio del minimo privilegio. Un’attività di riepilogo non dovrebbe concedere automaticamente accesso all’intera cronologia, ai metadati del profilo, all’esecuzione di codice o a una rete senza restrizioni.

Queste misure affrontano la combinazione più rischiosa: input non attendibile, contesto privato, esecuzione di codice e strumenti capaci di compiere azioni. Il comportamento di rifiuto del modello, da solo, non può costituire un confine di sicurezza sufficiente.

Il confronto con gli altri attacchi agli agenti AI

Il caso di Grok si inserisce in un modello più ampio: l’attaccante manipola il contenuto che l’agente deve elaborare e sfrutta poi i permessi legittimi dell’agente per completare l’operazione.

EchoLeak, che ha interessato Microsoft 365 Copilot, è stato descritto come una vulnerabilità di prompt injection senza clic in cui un’e-mail appositamente costruita poteva consentire l’esfiltrazione remota e non autenticata dei dati accessibili all’assistente. Uno studio accademico identifica il problema come CVE-2025-32711.

In un caso distinto, i ricercatori hanno descritto la catena CoSnitch contro Microsoft Copilot Personal: un link costruito ad hoc poteva avviare l’esecuzione di prompt e l’estrazione di dati dalle applicazioni collegate. Secondo i ricercatori, Microsoft ha distribuito le patch il 18 agosto 2026.

Un rischio analogo riguarda gli agenti per la programmazione, dove il vettore d’attacco può essere un repository anziché una pagina web. Adversa ha riferito che repository malevoli potevano sfruttare impostazioni e meccanismi di fiducia di diversi assistenti, tra cui Claude Code, Cursor CLI, Gemini CLI e Copilot CLI, per eseguire server MCP controllati dall’attaccante con privilegi potenzialmente estesi. Un’altra analisi di Adversa ha descritto un aggiramento delle policy basato su lunghe catene di comandi shell, con possibile furto di credenziali o segreti.

Il mezzo cambia — e-mail, URL, documento, repository, pagina cifrata o integrazione con uno strumento — ma la lezione architetturale resta la stessa: un agente non dovrebbe trasformare contenuti controllati dall’attaccante in autorizzazioni per leggere dati riservati o compiere azioni esterne.

La conseguenza più ampia per la sicurezza dell’AI

La Cryptographic Context Injection mostra perché la sicurezza degli agenti non può fermarsi alla scansione del testo che entra per primo nella finestra di contesto. Le istruzioni possono comparire dopo una decifrazione, un recupero da una fonte esterna, un’analisi, un’esecuzione di codice, l’accesso alla memoria o un’altra chiamata a uno strumento.

Se ogni trasformazione cancella l’origine dei dati, si crea uno spazio che l’attaccante può sfruttare: ciò che il sistema classificava inizialmente come non attendibile può essere trattato dal runtime come autorizzato in un passaggio successivo.

Per gli utenti, la lezione pratica è usare cautela quando si chiede a un agente con accesso a conversazioni private o strumenti operativi di elaborare pagine, documenti, link o repository sconosciuti. Per gli sviluppatori, la priorità è ancora più netta: bisogna applicare confini di fiducia nel runtime, ridurre l’accesso al contesto sensibile, limitare i parametri degli strumenti, controllare le connessioni in uscita e rendere visibili e confermabili le azioni ad alto impatto.

La tecnica segnalata contro Grok non rappresenta quindi una “rottura di AES”, ma un avvertimento sul riciclaggio dell’autorità. La cifratura può nascondere un’istruzione a un filtro, ma solo un runtime troppo permissivo può trasformare quell’istruzione nascosta in un’azione di furto dati.