OpenClaw patched a chain that started in a chat message

Researcher Chinmohan Nayak has written up three vulnerabilities in OpenClaw — a personal AI assistant that sits between the user and their host — that, when combined, take an inbound WhatsApp message and turn it into code execution on the machine underneath. All three are patched in OpenClaw 2026.6.6, which shipped ahead of the disclosure. There is no public proof-of-concept and no reported exploitation in the wild.

The three flaws are catalogued as GHSA-hjr6-g723-hmfm (OS command injection, CVSS 8.8), GHSA-9969-8g9h-rxwm (a second OS command injection, CVSS 8.8), and GHSA-575v-8hfq-m3mc (path traversal via symbolic-link following that reaches through the sandbox’s bind mounts, CVSS 8.4). The two injection bugs share a common root: the input filtering meant to catch shell metacharacters was incomplete. The traversal bug lets a caller step outside the mount points that were supposed to keep it contained. Nayak’s chain uses one of the injections to run something, and the traversal to widen what “something” can touch.

The blocklist story is the part worth sitting with. OpenClaw shipped with an explicit list of directories the assistant would refuse to look at — the familiar ones: ~/.ssh, ~/.aws, the places where a modestly careful attacker would start. That list is a fine idea in isolation. It stops working the moment somebody mounts a parent directory instead of the leaves, at which point the symlink follow inside the sandbox drops back into the very paths the list was written to protect. The block is what a developer would write down if asked to name the sensitive directories from memory. The escape is what somebody would write down if asked how to reach them without naming them.

There is a broader pattern here that isn’t specific to OpenClaw, and it is the reason this particular writeup is worth flagging rather than filing. AI assistants like this one are being wired directly into inbound message streams — chat, email, the calendar — on the assumption that the LLM in the middle is doing something useful with the untrusted string on its way to becoming a structured action on the host. What the LLM is not doing, at any point in that pipeline, is acting as a security boundary. The parser downstream still has to treat the message as attacker-controlled input; the sandbox still has to hold against everything it can hold against. The filter list around shell exec, the mount points around the filesystem, the blocklist around sensitive paths — those are still the actual boundary, and they are the ones that keep going wrong. The natural-language layer in front of them changes nothing about what they need to survive.

The specific class of bug is old. Filter-based defenses against shell injection were being written up as insufficient in the late nineties; symlink-following past bind-mount sandboxes was a well-understood escape long before any of this. The novelty is the delivery vector. An OpenClaw user who never runs an attachment, never clicks a link, and never opens a suspicious file can still receive a chat message that the assistant will helpfully act on. Nayak’s chain is what happens when that path is taken all the way through.

Upgrade to 2026.6.6. If OpenClaw was running with the Docker socket mounted, or with cloud-credential files inside the sandbox’s reachable tree, treat those credentials as touched — even without exploitation observed, the researcher’s description of the reachable surface is enough to warrant a rotation. The full technical writeup is on The Hacker News; the three advisories carry the vendor’s own patch notes.