New Attacks Trick OpenClaw AI Agent Into Running Code and Leaking Secrets

New Attacks Trick OpenClaw AI Agent Into Running Code and Leaking Secrets β€” Cybersecurity | Versia.media

Two security teams have demonstrated, through separate studies released this week, that OpenClaw, the widely used self-hosted AI agent, can be manipulated into executing attacker-controlled code or leaking sensitive data via seemingly normal inputs.

Imperva embedded instructions within shared contacts, vCards, and location pins that the agent executed without the victim ever noticing. Varonis created a test agent on the platform, equipped it with a mailbox containing simulated business data, and observed that a single standard email persuaded it to send mock AWS keys and a fake customer export to an external address.

The vulnerability discovered by Imperva has been fixed in OpenClaw 2026.4.23, so users should update if they operate the software. The phishing weakness identified by Varonis is not something a patch can resolve; it ultimately depends on restricting the agent's autonomous capabilities.

Different entry points lead to the same outcome: the agent trusts whatever it receives, and its access privileges become the attacker's.

Concealed commands within a shared contact

Imperva researcher Yohann Sillam examined how OpenClaw transmits messaging data to its underlying model. The issue lies in the architecture.

When the agent passes a shared contact, vCard, or location to the LLM, it flattens the object directly into the prompt text without any boundary marking it as untrusted. Content fetched from the web is wrapped in an untrusted-content marker, but message objects are not.

Only certain fields reach the model, and this is what the attack exploits. A shared contact sends just the name field, serialized as <contact: name, number>. The angle brackets are permissible within a name, so the model cannot distinguish where the actual name ends and an injected instruction begins. The contact name is truncated where it appears on screen, both on WhatsApp and in the receiving app, meaning the victim does not see the payload either.

The same technique works through a vCard's full-name field, which WhatsApp supports natively, and through the label on a shared location pin.

In Imperva's tests against Gemini 3.1 Pro (preview build), the hidden text instructed the agent to download and execute a script from a server the researchers controlled. It did so. A plain image with embedded instructions failed, likely because such attacks have been reported so frequently that models are now trained to resist them; the message-object route succeeded because models have encountered far fewer examples of it.

With OpenClaw's memory enabled by default, Imperva warns that a single piece of widely shared content carrying a hidden instruction could quietly compromise the agents that process it, if they are not sandboxed.

Imperva disclosed the issue, and OpenClaw delivered a fix in version 2026.4.23 that moves contact names, vCard fields, and location labels out of the prompt body and into a separate untrusted-metadata channel. Imperva found the same flattening pattern in other personal AI assistants, so the underlying problem is not exclusive to OpenClaw.

A standard email is sufficient

Varonis Threat Labs approached OpenClaw from the social perspective. In research led by Itay Yashar, the team built an agent called Pinchy on the platform, connected it to a Gmail inbox filled with realistic but synthetic business clutter and fake secrets, and ran it through four phishing simulations on Google Gemini 3.1 Pro and OpenAI Codex GPT-5.4.

They distinguish between prompt injection, which hides instructions in data, and what they call agent phishing: a believable request that arrives through a normal channel and works because the agent acts before verifying the sender.

The agent failed both exfiltration tests. In the first, a message posing as a team lead named Dan, sent from an external Gmail address, requested staging access during a fabricated production incident. Pinchy located the credentials and forwarded mock AWS IAM access keys, database connection strings, and SSH credentials in plaintext.

The second pretext was more subtle: a routine-sounding request for the weekly customer export, supposedly for a QBR deck. The agent sent out a synthetic dataset of 247 enterprise customers, including contacts and contract values. Both failures occurred under a strict profile that instructed the agent to verify senders first. The rule was in place. Urgency overrode it once, routine overrode it the second time.

The agent performed better when the threat was technical rather than social. It interacted with a gift-card phishing page but withheld real credentials and eventually flagged it; the strict profile blocked the page entirely. On a malicious OAuth consent screen disguised as a timesheet app, it examined the redirect target, deemed it suspicious, and halted before granting access.

That is the distinction Varonis highlights: the agent is more adept than many people at identifying bad URLs and fake login portals, and worse at the social judgment that makes a human pause when a colleague suddenly asks for credentials at an unusual hour. The drive to be helpful is the attack surface.

Varonis states that OpenAI Codex GPT-5.4 was more cautious than Gemini 3.1 Pro about entering or sending data to external sites without confirmation, but both fell for the social pretexts.

The vulnerability behind both attacks

Varonis maps both attacks onto what Simon Willison calls the lethal trifecta: an agent that can read private data, ingest untrusted content, and send data back out. OpenClaw possesses all three, which is why a poisoned contact and a friendly email lead to the same result.

That trust boundary is not just a prompt problem; it also appears in OpenClaw's code. A separate InfoSec Write-ups analysis converted OpenClaw's past advisories into static-analysis rules, then used them to discover five additional flaws across the Slack, Discord, Matrix, Zalo, and Microsoft Teams channel extensions.

All five were the same bug: the startup code resolved each channel's allowlist by mutable display name instead of a stable ID, so an attacker who renamed themselves to match an allowed user could slip onto the list and manipulate the agent. OpenClaw has patched these.

OpenClaw ships with broad access to files, shells, and more than twenty messaging platforms, and it has attracted a steady stream of earlier prompt-injection and data-exfiltration warnings since its launch late last year.

The Dutch data protection authority took the strongest stance: the Autoriteit Persoonsgegevens advised users and organizations not to run OpenClaw on systems that hold sensitive data, citing data-breach and account-takeover risks.

What to do about it

Anyone running OpenClaw should update to version 2026.4.23 or later for the message-object fix. The rest is about architecture, not prompt wording, and Varonis outlines four controls.

Treat the agent's instruction file as an enforced, version-controlled policy, not a suggestion. Outbound mail needs a gate: no first-time sends to unfamiliar addresses without approval, so a hijacked agent cannot relay phishing from a trusted account. Connector access should reflect the trust level of whatever triggered the task, so an inbox handling external email cannot also read the entire CRM. And the riskiest actions, such as forwarding credentials or moving money, should require human approval.

Both teams converge on the same mindset. Varonis frames it as treating the agent like a junior employee with system access and no intuition for what seems off, not as a security tool. Imperva approaches it from the other direction, calling it an authenticated executor that trusts its inputs.

The fixes available today are specific patches and guardrails. The harder problem remains unresolved. An agent useful enough to act on your email and execute your commands is, by design, one that trusts input and aims to help, and no one has a general solution for that yet.

← Cybersecurity