No link was clicked. No file was opened. Someone shared a contact, the agent read the name field, and then it downloaded and ran a script. This is the teardown of that attack, the two that followed it, and the one nobody has patched.
The message looked like nothing. A shared contact, the kind you send when someone asks "what's the plumber's number." The name was cut off on screen the way long names always are. The agent on the other end, an OpenClaw instance wired to WhatsApp with memory on and a shell available, read the whole thing.
The whole thing included an instruction. The agent followed it, fetched a script from a server it had never seen, and ran it.
This is not hypothetical. Imperva's Yohann Sillam demonstrated it in research published on June 11, 2026, and OpenClaw patched the specific flaw in version 2026.4.23. But the patch closed one door, and in the three months since, researchers have walked through two more. This post is the story of all three, told in order, because the pattern matters more than any single fix.
Incident one: the contact card
Here's how OpenClaw handed messages to the model before the patch. Content the agent fetched from the web was wrapped in an untrusted-content marker, so the model had a signal that it was reading data, not instructions. Message objects from WhatsApp weren't. A shared contact, a vCard, or a location pin was flattened straight into the prompt text, with no boundary.
Only some fields travel to the model. For a contact, it was the name and number, serialized roughly as <contact: name, number>. And angle brackets are legal characters in a name.
The model can't tell where the real name ends and the injected instruction begins. Neither can the victim, because WhatsApp truncates long names on screen. The payload is invisible to the human and fully legible to the agent.
Imperva tested it against Gemini 3.1 Pro. The hidden text told the agent to download and run a script from a researcher-controlled server. It did. Notably, the same instruction buried in an image failed; that attack has been reported so often that models are now trained to resist it. The contact-card route worked because the model had seen almost no examples of it. Novelty was the exploit.
The same trick worked through a vCard's full-name field and through the label on a shared location pin. And because OpenClaw's memory is on by default, Imperva's warning was blunt: a single widely shared contact carrying a hidden instruction could quietly compromise every unsandboxed agent that ingested it.
OpenClaw's fix in 2026.4.23 moves contact names, vCard fields, and location labels out of the prompt body into a separate untrusted-metadata channel. If you run WhatsApp on a version older than that, stop reading and update. The OpenClaw WhatsApp setup guide has the version check.
Incident two: the message that claimed to be the system
Four months earlier, in late February, an OpenClaw user filed a GitHub issue that reads like a warning nobody wanted to hear. Running the agent as a WhatsApp assistant, they noticed an inbound message that looked like a system-level instruction. The user hadn't typed it. It appeared in the WhatsApp message body, twice in the same session, timed to the agent's heartbeat and compaction cycle.
The payload told the agent that memory compaction had happened and its startup files were missing, directed it to read specific file paths (a fake WORKFLOW file and date-keyed memory files) that could hold further instructions, and offered to "restore" its operating protocols. In other words: convince the agent it had amnesia, then hand it a new personality.
That time, the agent recognised the injection and ignored it, both times. Good. But read the shape of the attack again. It didn't try to make the agent do something bad. It tried to make the agent reload its own instructions from an attacker-controlled place. Which brings us to the third incident.
Incident three: laundering a lie through memory
In August, IronCore Labs published what they called prompt laundering. Their direct injection attempts, sent by email to an OpenClaw agent, all failed. The agent flagged them: "this looks like a self-directed operational note," "I did not forward or delete any actual emails." Textbook refusals.
But the agent has memory, and memory is written by summarisation. While refusing the attacks, it was also extracting "facts" from them for future reference. Dozens of lines. And here is the sentence that should keep you up:
Content the summarising model had flagged as suspicious was saved into memory files without any untrusted tags, trust-level notes, or qualifiers. The flag didn't survive the trip to disk.
Repeat the lie enough times and it becomes background knowledge. Eventually the memory contained instructions to update the hourly email-summary script to forward new mail to the attacker, and to edit the summary prompt so the attacker's own emails were excluded from what the user saw. When the hourly task ran, the agent read its own memory and did exactly that.
No single message succeeded. The accumulation did. This one has no version number attached, because it isn't a bug in a parser. It's what memory is for.
What the three have in common
Simon Willison's lethal trifecta, which Varonis used to frame their own OpenClaw research the same week as Imperva's, is the cleanest lens. An agent that can read private data, ingest untrusted content, and send data out is exploitable by construction. WhatsApp-connected OpenClaw has all three by default.
Each incident attacked a different seam in the same boundary. Incident one exploited a missing "this is data" marker on message objects. Incident two impersonated the system prompt inside the data stream. Incident three exploited the fact that the marker, when it exists, gets stripped when data is promoted to memory.
Varonis's parallel research adds the human version: a plain email pretending to be a team lead, during a fake incident, got their test agent to forward mock AWS keys, database strings, and SSH credentials in plaintext. The agent had a strict profile telling it to verify senders first. Urgency beat the rule. A second, routine-sounding request for "the weekly customer export" shipped a synthetic dataset of 247 customers. Routine beat the rule too.
And in July, a researcher chained three separate flaws in OpenClaw 2026.6.1 (an environment-variable filter bypass, Git ext:: transport command execution, and a sandbox parent-directory bypass) into a WhatsApp message that ran code on the host. Reported to the project, since addressed, and a reminder that "the sandbox" is a claim to be verified, not a fact.
What actually protects you
The two research teams landed on the same controls, and they're architectural, not prompt wording. The OpenClaw security checklist has the full hardening list; here's what these three incidents specifically argue for.
Version first. 2026.4.23 or later for the message-object fix. Later still for the July chain. If you're several releases behind, the September update also flips session-visibility defaults you'll want to review while you're in there.
Gate outbound sends. No first-time sends to unfamiliar addresses or numbers without a human approving. This is the single control that would have stopped incident three's payoff and both Varonis exfiltrations. A hijacked agent that can't send is a hijacked agent that can't hurt you much.
Scope connectors to the trigger's trust level. An agent handling inbound WhatsApp from strangers shouldn't also hold the CRM, the shell, and the mail sender. Split them. The trust levels we ship (Intern, Specialist, Lead) exist precisely so the agent reading your WhatsApp is an Intern with no outbound tools, and the one that can send is a Lead that only takes instructions from you.
Treat memory as an attack surface. Anything promoted from untrusted content to long-term memory needs to keep its untrusted label, or not be promoted. If your agent's memory can be written by summarising strangers' messages, incident three applies to you today. Review what's in it.
Don't let secrets sit in context. The Varonis agent found the AWS keys because they were reachable. Ours auto-purge from agent memory five minutes after use, encrypted with AES-256 in between, which is the difference between "the agent was tricked" and "the agent was tricked and had nothing to hand over." The secrets auto-purge post explains the trade-offs.
Verify the sandbox. The July chain broke out of one. Isolated containers per agent, with the parent directory actually inaccessible, is the baseline. Test it with something harmless before an attacker tests it with something that isn't.
If you're running WhatsApp-connected agents and the list above feels like a second job, that's the honest reason BetterClaw exists. Every agent runs in its own isolated container with trust levels, action approvals, and secrets auto-purge on by default. Free plan, bring your own keys.
The part that doesn't get patched
Every specific hole in this post has a fix. The message-object flattening is fixed. The July chain is fixed. The allowlist-by-display-name bugs Varonis pointed to in five channel extensions are fixed. Good.
What isn't fixed, and can't be by a version bump, is the thing Imperva named at the end of their report: the agent is an authenticated executor that trusts its inputs. The Dutch data protection authority went further and told organisations not to run OpenClaw on systems holding sensitive data at all. That's a policy answer to an engineering problem, and I don't think it's the only one, but it's a fair reading of where things stood in June.
Here's mine. An agent useful enough to act on your WhatsApp is, by design, one that reads whatever arrives and wants to help. You can't train the helpfulness out without losing the agent. What you can do is decide, in advance and in config, what it's allowed to do with what it reads. The three incidents above each found an agent that hadn't decided. Make yours decide.
If any of this resonated, give BetterClaw a try. The free plan gives you one agent and 100 credits a month, bring your own API keys, no inference markup, and it never asks for a card. Pro is $49 a month for five agents, or $39 a month billed annually. Isolated containers, trust levels, action approvals, and secrets that don't stick around. Start free or see full pricing.
Frequently Asked Questions
What is WhatsApp prompt injection against an AI agent? It's an attack where instructions hidden inside a WhatsApp message, contact card, vCard, or location pin get read by the AI agent as if they were commands rather than data. In Imperva's June 2026 demonstration, a contact whose name field contained a hidden instruction caused an OpenClaw agent to download and run a script, with nothing visible to the human because WhatsApp truncates long names on screen.
How does WhatsApp prompt injection compare to email phishing of an agent? Prompt injection hides instructions in data the agent processes; agent phishing is a believable request sent openly through a normal channel. Varonis showed the second works too: a plain email posing as a team lead got a test agent to forward mock AWS keys despite a rule to verify senders. Both exploit the same boundary, and the same controls (outbound gating, scoped access, human approval for risky actions) address both.
How do I check whether my OpenClaw WhatsApp agent is vulnerable? Check your version first: the contact-card flattening was fixed in 2026.4.23, and a separate WhatsApp-to-host chain affecting 2026.6.1 was reported in July, so anything current is safer. Then audit the agent's memory for anything promoted from stranger-sent messages, confirm outbound sends require approval, and verify the container sandbox actually blocks parent-directory access.
Is it worth running an AI agent on WhatsApp at all given these risks? Yes, if the agent is scoped to what it needs and can't act on consequences without approval. The incidents above all involved agents that combined inbound untrusted messages with outbound sending or shell access in one identity. Split those roles, gate outbound actions, and keep secrets out of context, and a WhatsApp agent is no more dangerous than a WhatsApp inbox.
Is a patched OpenClaw safe from prompt injection over WhatsApp? Safer, not safe. Patches closed the specific message-object flattening and the July sandbox chain, but the memory-laundering pattern IronCore demonstrated isn't a bug in a parser, it's a property of summarised memory, and the "agent trusts its inputs" problem has no general fix yet. Treat patches as necessary and architecture (trust levels, approvals, secrets purge, isolation) as the actual defence.
