What are the OpenClaw vulnerabilities and who discovered them?

Security researcher Chinmohan Nayak discovered three high-severity flaws in the OpenClaw personal AI assistant: GHSA-hjr6-g723-hmfm and GHSA-9969-8g9h-rxwm (both CVSS 8.8, OS command injection in the host execution environment filter) and GHSA-575v-8hfq-m3mc (CVSS 8.4, path traversal allowing sandbox bind mounts to bypass parent-directory denylist checks). All three are patched in OpenClaw 2026.6.6.

How does the WhatsApp-to-host attack chain work?

An attacker sends a specially crafted message to a victim via WhatsApp. OpenClaw processes the message through its AI assistant pipeline. The path traversal flaw (GHSA-575v-8hfq-m3mc) bypasses the bind mount denylist by checking whether the source path is under a blocked directory but not the reverse. Mounting the /home parent directory allows reading every user's SSH keys, AWS credentials, and GPG secrets. Mounting /var exposes the Docker socket, enabling a full host escape from inside the sandbox.

What is different about these flaws compared to previous AI assistant vulnerabilities?

Unlike earlier vulnerabilities such as the Claw Chain issues disclosed by Cyera in May 2026, these three flaws do not require the attacker to establish any prior foothold on the target system. The full attack chain, from external WhatsApp message to host code execution and credential exfiltration, is possible without any prior access. This zero-prior-access property is what makes the WhatsApp delivery vector particularly concerning for users running OpenClaw with messaging integrations.

OpenClaw AI Assistant: WhatsApp Message to Host RCE

Three security flaws in OpenClaw, a personal AI assistant with WhatsApp and other messaging integrations, chain together to let a remotely-sent message trigger code execution on the host machine, steal SSH keys and cloud credentials, and escape to the Docker socket. The vulnerabilities were discovered by researcher Chinmohan Nayak and reported to The Hacker News this week. All three are patched in OpenClaw version 2026.6.6.

The attack requires no prior foothold. A message. That is the entire entry requirement.

What OpenClaw Is

OpenClaw is an AI assistant platform that connects large language models to channels including WhatsApp, Slack, and other messaging services, and extends them with tools: web browsing, code execution, file access, and shell commands. It is the kind of agentic AI setup that is increasingly common for individuals and small teams building personal productivity workflows, or developers building lightweight agent systems without a full enterprise deployment.

The architecture also creates a broad attack surface. An agent that can read files, execute code, and mount storage is a significant target if its sandbox controls fail.

The Three Flaws

GHSA-hjr6-g723-hmfm and GHSA-9969-8g9h-rxwm (CVSS 8.8 each) are OS command injection vulnerabilities in OpenClaw’s host execution environment filtering mechanism. Both affect the logic that is supposed to prevent tool calls from executing or persisting actions beyond the caller’s intended authorisation. When the filter fails, a tool invocation can run arbitrary commands on the underlying host.

GHSA-575v-8hfq-m3mc (CVSS 8.4) is where things get structurally interesting. This is a path traversal flaw in how OpenClaw’s sandbox manages bind mounts. The sandbox maintains a denylist of directories that should not be accessible from inside the container: ~/.ssh, ~/.aws, ~/.gnupg, and similar sensitive paths.

The problem is directional. OpenClaw’s getBlockedReasonForSourcePath() function checks whether the source path is under a blocked path. It does not check the reverse: whether a blocked path is under the source path.

Mount /home into your sandbox and you have read access to every user’s SSH keys, AWS credentials, and GPG secrets, because ~/.ssh is under /home. Mount /var and you get the Docker socket, which is full host escape.

The Attack Chain

Nayak demonstrated that the three vulnerabilities compose into a no-foothold attack path via WhatsApp:

An attacker sends a crafted message to a victim whose OpenClaw instance is connected to WhatsApp
OpenClaw’s AI assistant processes the message, invoking tool calls as part of normal operation
The command injection vulnerabilities in the host execution filter allow executing system commands
The path traversal flaw enables the sandbox to mount /home or /var
Credentials in ~/.ssh, ~/.aws, ~/.gnupg are accessible for exfiltration
Mounting /var provides access to the Docker socket, enabling container escape to the host

OpenClaw notes in its advisory that “practical impact depends on the operator’s configuration and whether lower-trust input can reach that path.” The WhatsApp integration puts lower-trust external input directly into that path by design.

What This Pattern Means

The OpenClaw vulnerabilities illustrate a recurring structural problem in agentic AI systems: the attack surface of a capable agent is determined by what the agent can do, not by what it is supposed to do. OpenClaw’s sandbox was supposed to constrain file system access to specific allowed paths. The directional error in one function’s logic was enough to undermine the entire control.

This is the same underlying category as the MCP tool-poisoning attacks that have dominated AI security research in recent months, in that the control boundaries of the agentic system are broader than the design assumes. The difference here is that the flaw is in the sandbox implementation, not in the model’s handling of instructions.

For anyone running AI assistants with messaging integrations and tool access: the threat model is not limited to prompt injection through the LLM. The execution environment itself is in scope.

Recommended Actions

Update OpenClaw to version 2026.6.6 immediately. All three vulnerabilities are patched in this release.

Before patching, restrict the affected features to trusted operators or disable the messaging integrations when not in use.

As hardening measures regardless of patch status: enable sandbox mode for all non-main sessions, remove exec from the tool allowlist for channel-facing agents (agents that receive external messages via WhatsApp or similar), and monitor for git clone commands using the ext:: external protocol helper, which can be abused to run arbitrary system commands.

Keep channel and tool allowlists narrow as a general principle. Avoid sharing one Gateway between mutually untrusted users.