Grok Vulnerable to Chat History Exfiltration via Cryptographic Context Injection

A new 'Cryptographic Context Injection' attack successfully exfiltrates chat history from xAI's Grok by hiding malicious instructions inside encrypted data. This technique bypasses simple prompt filtering and demonstrates a critical vulnerability for any LLM that ingests and acts upon untrusted web content. The bottom line is that giving a model tools to browse the web and also decrypt content on that same web page is a recipe for data leakage.

Security researchers at Adversa AI disclosed a new proof-of-concept attack that targets LLMs with web-browsing capabilities. The exploit is a stark reminder that if you let an LLM process untrusted content from the internet, you have to assume that content will try to hijack the model.

How does Cryptographic Context Injection work?

The attack embeds a malicious prompt inside an encrypted JSON object on a webpage. The same page includes a visible prompt telling the LLM to decrypt the object, providing the decryption key right there in the text. When a user asks Grok to summarize the page, the model follows these instructions.

First, Grok reads the page content, which tells it to decrypt a blob of data using a provided key. Upon decrypting the JSON, it finds a second, hidden set of instructions. This hidden prompt commands the model to take the user's entire private conversation history and send it via a POST request to an attacker-controlled server. The model executes this without any further user interaction or confirmation.

What broke?

The core failure is Grok's inability to distinguish between data to be processed and instructions to be executed. By following a seemingly benign instruction on a webpage (decrypt this text), it exposed itself to a malicious command injection. This isn't just a standard prompt injection; the cryptographic layer is used as an obfuscation technique to get the payload past any simple input filters that might be looking for suspicious keywords.

This vulnerability highlights the danger of giving models powerful tools—like the ability to make arbitrary network requests—and then pointing them at untrusted content that can instruct them on how to use those tools. The model is just following orders, and the orders came from a malicious source it was told to trust.

Should you use models with web browsing?

This specific exploit shows that features letting an LLM browse the web are still high-risk. Simply filtering for "bad words" in a prompt is useless when the payload is encrypted. The only reliable defense is aggressively sandboxing the LLM's capabilities. If a model can read from the web, it should not also be able to make arbitrary, un-proxied outbound network calls based on instructions found in that content.

My verdict is to avoid deploying features that combine browsing with tool use until stronger security paradigms are in place. If you must, treat all web content as hostile and strictly limit what the model is allowed to do in response to it. Don't let it decrypt and execute.

FAQ

Is this just another prompt injection attack? Yes, but it uses a cryptographic obfuscation layer. This method hides the malicious instructions inside an encrypted object, and the model itself is tricked into decrypting and executing the payload. This bypasses naive filters that scan for malicious command strings in plain text.

Does this only affect Grok? The proof-of-concept targeted Grok, but the principle applies to any LLM that has both web-browsing and tool-use capabilities. Any model that can be instructed to decrypt content from an external page and then act on it could be vulnerable to a similar attack vector.

How can I defend against this in my own application? Strictly sandbox the LLM's environment. Block or heavily proxy outbound network requests initiated by the model. Do not grant the model permissions to execute code or commands derived from untrusted web content. Treat external data as inert information to be summarized, not a command script to be executed.