A Web Page Can Make Grok Decrypt Its Own Attack Instructions

SINGAPORE, 26 AUG 2026 — Researchers have shown that an ordinary web page can carry encrypted instructions which xAI's Grok will decrypt inside its own code sandbox and then obey, sending the user's identity, approximate location, subscription tier and current conversation history to an attacker's address.

Adversa AI reported the technique, which it calls cryptographic context injection, to xAI and its HackerOne programme on 3 June 2026. It says it could still reproduce the chain on 19 August. There is no patch, no CVE and no mitigation timeline.

What the page actually contains

The payload is not hidden in the sense of being obfuscated or buried. It sits on the page in plain view as a block of AES-256-GCM ciphertext, next to the key material needed to open it and a short line telling the assistant to decrypt it in its Python runtime.

A human reading that page sees a meaningless blob. A content filter reading it sees the same. Neither can tell what the blob says, because neither is going to run the decryption.

Grok will. Asked to summarise the page, it follows the instruction, decrypts the ciphertext in its sandbox, and receives a set of commands which it then treats as its own working output rather than as text from a stranger's website.

Why encryption works where base64 would not

Encoding tricks are old and mostly solved. Base64, rot13 and simple substitution ciphers have all been used to smuggle instructions past filters. They stopped working reliably because a large language model can be trained to see through them, recovering the plaintext from its own weights. The plaintext is recoverable inside the weights, so the model can be trained or prompted to see through the wrapper, and the filter can be taught the same trick.

AES-256-GCM with a key derivation function is different in kind, not degree. No amount of training recovers the plaintext, because there is no pattern to learn — that is what the cipher is for. The only way to obtain the instructions is to execute the algorithm.

This inverts the usual relationship between a guardrail and an attacker. A content classifier inspects text; it does not run cryptography during inspection, and giving it that capability would mean executing attacker-supplied key material as a matter of routine. The filter cannot read the payload. The only component that can is the sandbox, which has no reason to be suspicious of its own output.

Trust laundering, and why the sandbox is the mechanism

The researchers call this trust laundering, and the term fits.

An assistant reasonably distinguishes between content it fetched from the internet, which deserves suspicion, and the output of its own tools, which it produced and can rely on. Running the decryption moves the attacker's text across that boundary. It enters as untrusted ciphertext from a web page and emerges as trusted plaintext from the model's own interpreter.

Nothing in that sequence is a bug in the ordinary sense. The sandbox executed the code it was given. The model trusted its own tool output, which is what tool output is for. The classifier passed text it could not read, which is the only thing it could do. Each component behaved correctly and the composition leaks.

We described the same shape in the Copilot chain patched last week, where base64 encoding was used to slip data past filters that inspect what the model is about to emit. This is the successor to that technique, and the escalation is specific. Where base64 defeated the filter but remained legible to the model, encryption defeats the filter by being illegible to everything except the code runtime.

Zero-click is the wrong label

Much of the coverage describes this as a zero-click attack. That overstates it, and the overstatement matters because it changes who is at risk.

The chain requires the user to ask Grok to summarise the attacker's page. That is one deliberate action, taken by a person who chose the link and chose to hand it to the assistant. Nothing happens to a user who never does so.

What is absent is any second decision. The user sees no consent prompt and no visible instruction to approve or refuse. They ask for a summary and they get one. So the accurate description is that the attack needs exactly one ordinary action and gives the user no opportunity to intervene after it — which is a serious property, and not the same claim as requiring nothing at all.

Eighty-four days, and what the silence means

The disclosure record is unusually clear. The report went in on 3 June. xAI acknowledged the ticket and gave no mitigation timeline. Follow-ups on 4 August and 10 August drew no reply. The chain still worked on 19 August, and by the time of this report roughly 84 days have passed.

Against the widely observed 90-day norm, that window is nearly closed. The delay is worth reading carefully. There is no clean fix; you cannot patch out the ability to decrypt without removing the code interpreter, and the durable answer is to stop treating tool output derived from untrusted input as trusted, which is an architectural change rather than a patch.

What is harder to defend is the absence of a reply. An acknowledgement without a timeline, and then two unanswered follow-ups, leaves a researcher holding a working exploit and no information about whether anyone is acting on it.

What a forty per cent success rate actually measures

Roughly forty per cent across about twenty attempts sounds like an unreliable attack. Read the failure mode and it looks different.

The researchers report that the failures came from decryption errors — the model fumbling the cryptographic step — rather than from a guardrail stopping the attempt. A finicky mechanism is not the same as a working defence.

An attack that fails because it was blocked is bounded by the defence. An attack that fails on execution errors is bounded only by engineering effort, and it can be retried against the same target at no cost. Forty per cent is a floor produced by a proof of concept, not a ceiling imposed by xAI.

What it means from here

For anyone deploying an assistant with a code interpreter over corporate content, the transferable control is not a better classifier. Filters cannot solve this class of problem. Adding cryptography, as this case demonstrates, puts the payload permanently outside what inspection can reach.

The question to ask of any such deployment is whether tool output is trusted differently depending on where its input came from. In most current designs it is not: the interpreter's result is the interpreter's result, regardless of whether the code arrived from the user or from a page the model happened to read. Until that provenance is tracked, the sandbox is a laundering service.

The narrower advice is unglamorous. If an assistant with a code runtime can also reach a user's conversation history and account details in the same context, the exposure is the combination and not either half. Turning off the interpreter for browsing sessions costs a feature and closes the chain.