The Grok Attack That Hides Inside Encryption
Adversa AI built a web page that ships an AES-encrypted payload, gets Grok to decrypt it with its own code tool, and walks the user's name, location, tier, and chat history out through a URL. Reported June 3. Still unpatched.
Adversa AI disclosed an attack on August 20 that it calls cryptographic context injection. The short version: a malicious web page can carry instructions that no content filter can read, because they are encrypted — and then get the model to decrypt them itself.
The researcher, Rony Utevsky, reported it to xAI and its HackerOne program on June 3, 2026. He followed up on August 4 and August 10. As of the August 19 reproduction against Grok 4.5 Fast at grok.com, there was no patch, no CVE, and no workaround.
How it works
The chain has five steps and each one uses a capability that is supposed to be there.
- An attacker-controlled page contains encrypted JSON alongside plain-language instructions describing how to decrypt it.
- Grok runs Python — a normal, advertised capability — to derive the key with PBKDF2 and decrypt the payload with AES-256-GCM.
- The safety classifiers never see the malicious instructions, because at the moment those instructions pass through the guardrails they are ciphertext. Ciphertext is not text a classifier can evaluate. It is noise.
- The decrypted instructions, now inside the model's context as trusted content it produced itself, tell the agent to build a URL with the user's session data as query parameters.
- Grok's navigation tool loads that URL. The data lands on attacker infrastructure.
What leaves: the user's name, approximate location, subscription tier, and the prompts from the ongoing conversation.
Adversa reports 20 attempts since June with a 40% success rate. Crucially, the failures were not the guardrails working. They were Grok getting the decryption wrong. Nothing in the pipeline flagged the prompt or the response.
Why this is a category problem, not a bug
Every guardrail architecture in production today makes the same assumption: that the thing entering the model's context can be inspected before it gets there. Content classifiers, prompt filters, injection detectors — all of them read the input and decide.
Encryption breaks that assumption cleanly. The filter's job is to evaluate meaning, and ciphertext has no meaning until after the model has already done the work of decrypting it. By the time the instructions exist in a readable form, they exist inside the trusted context, produced by the model's own tool call. The guardrail was never bypassed. It was made irrelevant.
This is the structural weakness of tool-using agents stated as plainly as it has been stated so far. Code execution and web navigation are the two capabilities that make an agent useful. They are also, composed together, a decryption engine attached to an exfiltration channel.
Not every model fell for it. Adversa reports that Gemini in Deep Thinking mode was vulnerable to a variant, with the success rate declining through August — suggesting Google shipped mitigations. GPT-5 and Claude Sonnet 4.5 resisted the technique.
That spread is the useful part of the finding. It means this is not an unavoidable property of tool-using models. It is a defensible surface that some vendors have defended and at least one has not.
The eleven weeks
The disclosure timeline is the part that should bother security teams more than the technique.
June 3 report. Silence. August 4 follow-up. Silence. August 10 follow-up. Silence. August 19 reproduction confirming the attack still works. August 20 publication, with xAI acknowledging the report but providing no mitigation details and no timeline.
Eleven weeks is not an unusual patch window for a complex vulnerability in a shipped product with a release train. It is an unusual window for a live service where the vendor controls the entire stack and can change model behavior, tool permissions, or navigation policy server-side on any given afternoon.
The available mitigations are not exotic. Restricting the navigation tool from loading URLs whose parameters contain session-derived content would break the exfiltration step. Refusing to execute decryption routines on content sourced from untrusted pages would break step two. Neither is free — both cost real capability — but both are the kind of trade-off a vendor makes when the alternative is a live data-leak path.
What to do about it
If you use a browsing-and-code-executing agent on pages you did not author, assume anything in the session can leave the session. That is not a Grok-specific caution; it is the correct threat model for the entire product category, and this disclosure is simply the clearest demonstration of it.
For anyone building on these agents: the defensive line is not the input filter. It is the egress. Whatever the model decides to do, the tools it can reach determine what damage is possible. Constrain URL construction, constrain outbound navigation, log egress destinations, and stop treating the model's own tool output as trusted content.
The industry has spent two years hardening the front door. This attack walked in through a window that the model opened, from the inside, because it was asked politely and in a language the guards do not speak.