Security researchers at Adversa AI demonstrated that a prepared webpage could make Grok expose data from the current conversation after the user asked the agent to summarize the page. The page carried encrypted instructions that Grok decrypted inside its Python runtime. The agent then treated the plaintext as trusted output and opened an external URL containing the user’s name, coarse location, subscription tier, and prompts from that conversation.
This was a controlled proof of concept, not a confirmed mass breach. The report does not say that every Grok chat leaked or that ordinary use without agentic web browsing triggered the attack. Adversa says it reported the issue to xAI on June 3 and could still reproduce the Grok chain on August 19; no public xAI mitigation confirmation was found at publication time.
What the Grok proof demonstrated
| Question | Evidence-based answer |
|---|---|
| What triggered the chain? | A user asked Grok’s web-browsing agent to summarize or analyze an attacker-prepared page. |
| Why did static guardrails miss it? | The page presented AES-encrypted ciphertext plus decryption instructions. Recovering the plaintext required execution in the runtime rather than ordinary text inspection. |
| What data appeared in the outbound request? | The proof showed the user’s name, coarse location, subscription tier, and prompts from the current conversation. |
| Was encryption broken? | No. Grok was given the material and instructions needed to decrypt the payload; the flaw was the trust assigned to the runtime result. |
| Was this exploited in the wild? | The report describes a controlled demonstration and does not report an active campaign, mass breach, or victim count. |
| Is there a CVE or confirmed fix? | No CVE is named. Adversa reported reproducibility on August 19 and said xAI had not provided a mitigation timeline. |
How Cryptographic Context Injection crossed the trust boundary
- Untrusted content entered through browsing. The attacker controlled a page that the user asked Grok to process.
- The visible input stayed opaque. Static safety checks saw ciphertext and instructions to decrypt it, not the hidden command itself.
- The runtime materialized the command. Grok used its code environment to decrypt the block. The resulting plaintext appeared as output from a tool the agent had just run.
- A privileged tool acted on that output. The decrypted instruction caused the browsing framework to open an attacker-controlled destination with private conversation context embedded in the URL.
The important failure was not cryptographic weakness. It was provenance loss: data derived from an untrusted page gained the authority of internal runtime output. A related AWS Kiro prompt-injection case crossed a different boundary—from hidden web text to a local MCP configuration and command—but illustrates the same need to keep fetched content from driving privileged tools.
Does ordinary Grok use mean your chat history leaked?
No. The demonstrated path required Grok’s agentic browsing flow to process a prepared page. It did not show passive compromise from visiting grok.com, asking an ordinary question, or viewing a page in a normal browser.
- You did not ask Grok to open or summarize external pages: the published proof does not describe your workflow.
- You analyzed a known page in a nonsensitive conversation: the precondition may overlap, but there is no evidence that the page was malicious or that the proof was used against you.
- You asked Grok to analyze an unknown or untrusted page: preserve the page URL, conversation link or identifier, and approximate time. Do not ask the same agent to reopen the page while investigating.
- The same conversation contained passwords, API keys, private documents, health data, financial details, or customer information: treat those specific items as possible exposure candidates if the page was suspicious. Do not assume unrelated chats or the whole account archive were included.
This scope distinction also matters in other AI privacy incidents. The Grok Build repository-upload case involved source code and Git history through a separate product and data path; it is not evidence for this chat-browsing vulnerability.
What to do after Grok summarized an unknown page
- Stop replaying the request. Save the page URL, the Grok conversation identifier, the time, the prompt you used, and any visible tool activity. Avoid loading the suspicious page again through the same conversation.
- Inventory the current conversation. List the personal details, files, credentials, secrets, and business information actually present in that thread. The proof concerns current-conversation context, so do not inflate the scope without evidence.
- Revoke real secrets from a separate trusted session. If a live password, API key, token, recovery code, or private link appeared in the chat, revoke or rotate it at the issuing service. Changing an account password is useful only for credentials that were actually exposed; it does not recall conversation data already transmitted.
- Review related activity. Check sign-in history, API usage, cloud audit logs, repository events, payment alerts, and file-access records relevant to the data in the conversation. Escalate unusual activity through the service’s normal incident process.
- Use Grok data controls deliberately. xAI documents options to delete individual or all conversations and to use Private Chat. Those controls reduce retained account data, but deletion can take up to 30 days and cannot reverse an outbound request that already reached another server.
- Report the suspected session. Contact xAI support with the account, conversation identifier, page URL, and time. Share sanitized evidence rather than pasting another secret into a support form.
If you need to inspect a file mentioned in the conversation, avoid creating a second disclosure while investigating. Our private-file upload guide explains when a hash lookup or an approved private workflow is safer than uploading the original file to a public scanning service.
What AI-agent builders should change
- Keep untrusted web content in a context without credentials or privileged tools, and pass only structured data into the trusted workflow.
- Preserve provenance after transformations. Decrypted or parsed text should remain marked as derived from an untrusted page.
- Require confirmation or a hard policy decision before contacting a new network destination, especially when the resolved arguments contain conversation or account data.
- Record per-session tool calls and fully resolved arguments so defenders can reconstruct what the agent read, transformed, and sent.
- Detect the sequence—untrusted content, decryption or code execution, then unexpected egress—instead of relying on one signature for a ciphertext block.
What remains unconfirmed
Adversa withheld operational payloads and disclosed a controlled attack, which is appropriate for reducing copycat risk. The public evidence does not establish in-the-wild exploitation, a mass user breach, a CVE, or access to every conversation in a Grok account. It also does not make the separate Gemini safety-bypass demonstration a Grok-style data-theft event.
Until xAI publishes a technical advisory or mitigation status, the strongest defensible user guidance is narrow: avoid asking a privileged browsing agent to analyze unknown pages inside conversations that contain secrets, preserve evidence after a suspicious session, and rotate only the credentials or tokens that were actually present.
References
- Utevsky, Rony. “Zero-click Grok data theft: Cryptographic Context Injection attack leaks chat histories.” Adversa AI, August 20, 2026. https://adversa.ai/blog/cryptographic-context-injection-grok-data-theft/
- xAI. “Consumer FAQs.” xAI, accessed August 23, 2026. https://x.ai/legal/faq
