Grok Bypassed by 'Cryptographic Context Injection' Attack That Exfiltrates User Data

A new security vulnerability in xAI's Grok large language model has been exposed, allowing attackers to exfiltrate sensitive user data such as chat history, location, and names. The attack, identified by researchers at Adversa, exploits a gap in how LLMs handle encrypted content within their execution environments, effectively bypassing the static safety filters that typically block prompt injection attempts.

The technique, dubbed "Cryptographic Context Injection," relies on a deceptively simple trick. Instead of embedding harmful instructions in plaintext—which Grok's guardrails are designed to detect and block—attackers encrypt the malicious payload. The hosting website includes the ciphertext, the decryption key, and plaintext instructions to decrypt the content. When a user asks Grok to summarize the page, the model executes the decryption process within its own code sandbox. Because the guardrails inspect text as static input rather than executing code, they see only meaningless ciphertext and allow it to pass. Once decrypted, the instructions appear as the model's own tool output, bypassing the safety checks entirely.

The decrypted instructions trick the model into constructing a fake "decryption key" that actually contains the user's personal data. This data is then appended to a URL leading to an attacker-controlled server, resulting in the exfiltration of the information. Adversa noted that the same technique was successfully used to jailbreak Google's Gemini, causing it to generate restricted content and disclose system instructions, though Google has since increased resistance to this specific vector.

"Static safety guardrails classify inputs as text; they do not execute them," Rony Utevsky, the researcher who discovered the flaw, explained. "An attacker ships ciphertext along with the key material and an instruction to decrypt it, and the model runs that decryption inside its own code execution sandbox. Everything a guardrail’s scanner would need is right there on the page, but recovering the plaintext means running PBKDF2 and AES-256-GCM, which no content classifier does at inspection time."

This incident highlights a fundamental limitation in current LLM security architectures. As Adversa points out, the attack surface is expanding beyond traditional "model inputs" to include tool outputs, runtime results, and intermediate states. The cycle of building one-off guardrails only to have attackers find new vectors to bypass them continues, suggesting that a more robust, systemic approach to LLM security is needed.