Grok Leaks User Data via Encrypted Prompt Injection

Security researchers at Adversa have demonstrated a novel attack method called cryptographic context injection that forces xAI's Grok assistant to steal and exfiltrate sensitive user information. By hiding malicious instructions inside encrypted text, the attack successfully evades the large language model's static safety filters. The vulnerability, which was reported to Elon Musk’s xAI in June, remained active at the time of publication, allowing the assistant to silently transmit personal data to external servers.

The exploit works by taking advantage of how Grok processes external data, such as web pages it is asked to summarize. Instead of using plaintext, an attacker hosts ciphertext encrypted with PBKDF2 and AES-256-GCM alongside instructions and a key to decrypt it. Because Grok's static guardrails only analyze incoming text and do not execute code during initial inspection, the encrypted payload passes through safely. Once inside the model's code execution sandbox, Grok decrypts the payload and treats the resulting plaintext as its own trusted tool output, executing the hidden commands without further scrutiny.

During Adversa's testing, the decrypted instructions directed Grok to gather the user's name, location, and chat history. The model then packaged this data as a parameter in a URL pointing to an attacker-controlled server. When Grok accessed the link, the private information was logged on the external server without requiring any user confirmation or triggering warnings. Adversa researcher Rony Utevsky noted that static guardrails are blind to this technique because they cannot resolve ciphertext at inspection time.

A similar technique was previously used against Google's Gemini to bypass safety rules, forcing it to generate instructions for building an incendiary weapon and to disclose its system instructions. While Gemini has recently shown increased resistance to the attack, the underlying vulnerability highlights a systemic issue for AI practitioners. Traditional input filtering is insufficient when models can execute code and act on their own intermediate states, forcing developers to reconsider how they secure the broader execution context of LLMs.