Researchers Encrypted a Prompt Injection. Grok Decrypted It and Leaked the User's Chat.

The filter read the page and saw nothing worth stopping

In a demonstration reproduced on 19 August 2026, a researcher asked Grok to summarize an ordinary web page. Grok read the page and summarized it. It also sent his name, his approximate location, his subscription tier and the conversation he was having to a server he did not control. There was no confirmation step and no visible warning.

The same instructions, written in plain English on the same page, get refused. The only thing that changed is that this time they arrived encrypted, and the model was handed the key. That single difference is the entire finding, and it points somewhere uncomfortable. The guardrail was never guarding the model. It was guarding the doorway, and the model was persuaded to build a second door.

How the attack actually works

Security firm Adversa AI published the technique on 19 August 2026 under the name Cryptographic Context Injection. The target was the Grok web chat at grok.com running Grok 4.5 Fast, and lead researcher Rony Utevsky reports 20 attempts since June with a 40 percent success rate. Adversa says it reported the issue to xAI on 3 June 2026, and to xAI's HackerOne bug bounty programme the same day, that xAI acknowledged the report without offering a mitigation timeline, and that follow-up attempts on 4 and 10 August went unanswered. There is no patch, no CVE identifier (the public catalogue number assigned to a disclosed vulnerability) and no setting a user can change. Adversa reports no exploitation in the wild.

The attacker's page carries three things: an encrypted block of JSON, the key material needed to open it, and a line telling the assistant to decrypt. A guardrail classifier, meaning the input filter that scans incoming content for malicious instructions, reads that page and finds ciphertext, which is to say nothing it can evaluate, so it lets the page through. Grok then does as it was asked and performs the decryption inside its own Python sandbox, deriving the key with PBKDF2 and opening the block with AES-256-GCM. The recovered instructions now enter the model's context not as text scraped off a stranger's website but as the output of code the model itself just ran. Provenance is laundered in that one step. What those instructions ask for is the neat part. The model is told to build an additional decryption key which is not key material at all, but a template string interpolating the user's name, location, subscription tier and chat history, and then to open a URL in order to fetch further context. Grok calls its own navigation tool, and the data leaves inside the query string.

• Adversa is the only source for the Grok finding and is withholding the working payloads. The 60 percent of attempts that failed did so because Grok mishandled the decryption, not because a filter caught the payload.
• A second demonstration in the same write-up targeted Google's Gemini in Deep Thinking mode, where a decrypted payload resolved into a fabricated Python traceback carrying a bogus safety-policy deactivation callback. Adversa says it produced restricted content and reproduced Gemini's system instructions. Google was not notified, because jailbreaks fall outside the scope of its disclosure programme.
• Independent academic work presented at USENIX Security 2026 by researchers at UC Berkeley, the Ethereum Foundation and NYU Shanghai found the same pattern using a far cruder cipher. A substitution cipher decoded in one turn and acted on in a second succeeded against Grok 3 on all twelve malicious requests tested, while the identical cipher without that second activation turn failed on all twelve.

Why it matters

Begin with the person using the chatbot, because there is nothing for them to do. No patch exists, no toggle helps, and xAI has held the report since early June. This is also not the first time: in December 2024 the researcher Johann Rehberger demonstrated an end-to-end exfiltration chain against Grok inside the X iOS app, and the reports he filed were closed as informational. The usable advice today reduces to not asking Grok to read pages you did not write yourself.

Your own exposure is wider than one chatbot, and it is worth checking this week rather than next quarter. Any agent you run that can both execute code and reach the network already has the ingredients, because it is those two capabilities sharing a single context that constitutes the vulnerability. Ask whoever owns your AI tooling one plain question: when the agent fetches something from the open internet, does that content arrive on the same channel as your own instructions? If the answer is yes, or if nobody knows, the input filter in your stack is doing considerably less than its invoice suggests. The systemic point is the one to carry away. A classifier can only judge text it can read, while an agent that can run code can manufacture text no classifier ever saw, out of input no classifier could evaluate. Encryption is simply the tidiest proof. A substitution cipher, an obfuscated script, a compressed archive, anything the model will compute and the filter will not, is the same attack in different clothes. Adversa's own conclusion is that the fix does not belong at the model layer at all, but in the harness around the agent: what identity it runs as, what it can reach, and what you can replay afterwards.

What to do about it

1. Fetch untrusted content in a context that holds no tools and no credentials. Return only structured data to the privileged agent, because this attack needs the fetched page and the tool-calling context to be the same place.
2. Gate outbound calls on fully resolved arguments rather than templates. The stolen data here only became a payload at the moment of interpolation, so a review step that sees the final URL catches it and one that sees the template does not.
3. Log every tool call with its resolved arguments, and alert on the sequence rather than the payload. An opaque blob paired with an instruction to decrypt it deserves a human look rather than a hard block, and without per-session traces you have neither the detection nor anything to reconstruct afterwards.

Bottom line

Nobody lost money here and no system was breached. A researcher put a locked box on a web page, handed the model the key, and watched a guardrail wave it through for the simple reason that a guardrail cannot read a locked box. Take that to your next security meeting, because it reframes what an input filter is actually for. Filtering the text an agent receives is not the same thing as controlling what ends up in its context, and the distance between those two ideas is exactly as wide as the tools you handed it. Adversa's write-up sets out the chain in full, and the USENIX Security 2026 paper documents the two-turn cipher pattern across models.