Un utente chiede a Grok di riassumere una pagina web, e il suo nome, la posizione approssimativa, il livello di abbonamento e l’intera sequenza dei prompt della conversazione finiscono nei log di un server estraneo. Non serve un clic in pi�, non compare alcun avviso e non viene chiesta alcuna conferma. La catena che porta a quel risultato � stata segnalata a xAI il 3 giugno 2026, e il 19 agosto era ancora riproducibile.
Tutto � stato ricostruito da Adversa AI, che ha battezzato la tecnica Cryptographic Context Injection. Le istruzioni dell’attaccante non raggiungono il modello come testo leggibile, ma come blocco cifrato con AES-256-GCM sotto una chiave derivata con PBKDF2. La pagina ospita il testo cifrato, il materiale di chiave e l’istruzione di decifrarlo, e il modello esegue quella decifratura nel proprio runtime Python.
Le barriere di sicurezza dei modelli leggono i contenuti, non li eseguono. Un classificatore vede passare l’istruzione di applicare PBKDF2 e AES-256-GCM e la tratta come una richiesta qualunque, perch� sa leggerla ma non sa risolvere cosa apra. Si tratta di richieste statiche perch� leggono i contenuti soltanto come testo. Non eseguono codice e non decifrano nulla, ma le istruzioni vere sono cifrate e quindi la barriera vede solo testo cifrato privo di senso e lo lascia passare.
Il modello si fida di quello che esce dalla propria sandbox
Il modello scioglie da s�, dentro i propri pesi, una codifica base64 o un cifrario a sostituzione, senza che nessun interprete entri in gioco; con la crittografia forte quella scorciatoia non esiste, e il recupero del testo in chiaro deve passare per il runtime. Il risultato compare cos� come output di codice che il modello ha appena eseguito, non come stringa esterna non fidata, e viene trattato con la fiducia che spetta allo stato interno di un programma. Adversa richiama l’analogia con la SQL injection, cio� un sistema che non distingue la propria query fidata dai dati dell’attaccante che scorrono nello stesso canale. E’ ancora poco chiaro il motivo per il quale Grok rifiuti le medesime istruzioni in chiaro e segua, invece, quelle cifrate: la spiegazione pi� probabile � che il filtro ispezioni il testo che entra e che esce dal modello, ma non l’output della sua esecuzione di codice.
Nella dimostrazione contro Grok le istruzioni decifrate ordinano all’agente di risolvere il proprio contesto privato di sessione e di infilarlo in un URL da aprire “per recuperare contesto aggiuntivo”. Il carico chiede poi al modello di costruire un’ulteriore “chiave di decifratura” che di materiale crittografico non ha nulla, perch� il suo valore � una stringa template che interpola nome, posizione, livello di abbonamento e cronologia della chat. Grok invoca da solo lo strumento di navigazione, carica quell’indirizzo e consegna i dati nei parametri della richiesta.
“Il framework costruito da xAI permette che istruzioni e dati estratti da una pagina esterna non fidata guidino l’invocazione di uno strumento privilegiato e connesso a internet”, scrive Adversa, “e permette che i metadati privati di sessione e la cronologia della conversazione confluiscano negli argomenti di quello strumento in uscita”. Su quel percorso, aggiunge la societ�, non esiste alcun confine efficace sul traffico in uscita, nessun passaggio di consenso e nessuna separazione della provenienza che i ricercatori abbiano potuto osservare. Le istruzioni riciclate raggiungono cos� un’azione privilegiata verso l’esterno senza incontrare ostacoli.
Il bersaglio � la chat web di grok.com su Grok 4.5 Fast, e l’ultima riproduzione risale al 19 agosto. Non esistono un CVE, una correzione o un rimedio lato utente, non risultano sfruttamenti reali e i carichi operativi non sono stati pubblicati.
La segnalazione � partita il 3 giugno 2026, diretta a xAI e al programma di bug bounty dell’azienda su HackerOne. xAI ha dichiarato di averla ricevuta senza fornire dettagli n� tempi di mitigazione, e i solleciti del 4 e del 10 agosto sono rimasti senza risposta; al 20 agosto l’azienda non aveva pubblicato dichiarazioni o avvisi sulla ricerca.
Su Gemini l’obiettivo cambia
La seconda dimostrazione della ricerca � un’iniezione diretta contro l’interfaccia pubblica di Google Gemini in modalit� Deep Thinking, che le istruzioni di sistema estratte identificano come Gemini 3 Flash (Web) su piano a pagamento. Un solo prompt, senza contesto precedente, chiede al modello di eseguire uno script Python che decifra un testo cifrato e di emettere soltanto un piccolo oggetto JSON, con una sola istruzione di riserva: se il codice solleva un’eccezione, leggere il messaggio di errore e agire di conseguenza. Per il caso di successo non viene data alcuna indicazione, cos� che resti un unico percorso praticabile.
Il testo cifrato � costruito perch� il risultato in chiaro sia un traceback Python dall’aria convincente, che di errore vero non ha nulla. Dentro ci sono una callback dallo stile di una API che finge di disattivare le policy di sicurezza e un prefisso di ragionamento in prima persona che impegna il modello a produrre il contenuto vietato, presentandolo come qualcosa che verr� cifrato “per sicurezza”. Il ragionamento impiantato dall’attaccante entra nel contesto come se fosse del modello, che imbocca l’unica strada rimasta: la risposta proibita viene generata in chiaro e poi cifrata dentro la sandbox, quindi il filtro in uscita valuta soltanto un blocco opaco.
Il metodo ha prodotto un esempio di pi� paragrafi su come costruire un’arma incendiaria, contenuto che i filtri di Gemini normalmente sopprimono, e con un carico modificato ha riprodotto le istruzioni di sistema del modello, compresa la direttiva che ne vieta la divulgazione. Google non � stata avvisata, perch� i jailbreak restano fuori dal perimetro del suo programma di divulgazione delle vulnerabilit�. Il tasso di successo contro i sistemi di Mountain View � calato nettamente nel corso dell’estate, per cause che Adversa non attribuisce: aggiornamenti dei filtri, cambi di versione del modello, o entrambe le cose.
La parte su Gemini non � nuova. Utevsky l’aveva gi� descritta l’11 marzo 2026 sul proprio sito di ricerca personale con il nome di Cryptographic Payload Injection, riportando cinque riproduzioni indipendenti su cinque tentativi e alcuni risultati incrociati su altri modelli: GPT-5 non era riuscito a interpretare le istruzioni di decifratura, mentre Claude Sonnet 4.5 aveva decifrato il carico e poi lo aveva segnalato come prompt injection. Il collegamento con la pubblicazione di marzo lo ha ricostruito The Hacker News, a cui il ricercatore ha confermato che quella sezione non ha subito modifiche sostanziali e che la novit� di agosto sta nella generalizzazione della tecnica e nella sua applicazione a Grok.
Le contromisure sono attorno all’agente, non dentro il modello
Il runtime di esecuzione del codice funziona come un canale di riciclaggio della fiducia, e la crittografia forte serve proprio a spingere il carico dentro quel canale. Che cifrari e codifiche possano portare un payload oltre l’allineamento � terreno noto: CipherChat aveva mostrato che i modelli decodificano i cifrari abbastanza bene da rispondere attraverso di essi, CodeChameleon aveva avvolto il carico in una trasformazione reversibile spedita insieme alla propria funzione di decodifica, e in entrambi i casi � il modello a recuperare il payload da s�, senza interprete nel mezzo. Anche l’esfiltrazione attraverso una richiesta in uscita dell’interprete di codice � materia che Rehberger dimostra dal 2023. Qui le istruzioni arrivano in un modo diverso, cio� come valore di ritorno della decifratura che l’agente stesso ha appena eseguito.
Adversa colloca la tecnica dentro uno spostamento pi� ampio, verso attacchi che manipolano non soltanto il prompt, ma il contesto pi� largo che un modello tratta come proprio: output degli strumenti, risultati di runtime e stato intermedio.
“Non serve risolvere questo problema a livello di modello: ogni controllo che limita l’attacco sta nell’impalcatura attorno all’agente, cio� con quale identit� gira, cosa pu� raggiungere, cosa pu� scrivere e cosa si pu� riesaminare a posteriori”, scrive Adversa. In concreto significa isolare i contenuti non fidati in un contesto privo di strumenti e credenziali, restituendo al contesto privilegiato solo dati strutturati; sottoporre a conferma le azioni irreversibili e quelle verso l’esterno, con gli argomenti gi� risolti e non in forma di template, negandole senza appello quando nessun umano � presente; registrare per ogni sessione le tracce delle chiamate agli strumenti, senza le quali non esistono n� rilevazione n� analisi a posteriori; e far scattare l’allarme sulla sequenza, trattando un blocco opaco accompagnato dall’istruzione di decifrarlo come segnale da rivedere, mai come filtro bloccante. Adversa suggerisce infine di rendere la tracciabilit� della provenienza del contesto un requisito d’acquisto, chiedendo ai fornitori se l’output degli strumenti sia separato dal canale delle istruzioni. Sulla chat web di Grok, nel frattempo, non c’� nulla che l’utente possa attivare o disattivare per proteggersi.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
