OpenClaw Claw Chain: 4 CVEs from OpenShell TOCTOU to MCP loopback owner spoof

TL;DR

OpenClaw’s Claw Chain is not just “OpenShell had four bugs.”
It’s a problem where the file access, environment variables, MCP loopback, and Gateway configuration powers an AI agent holds get linked together by an attacker on the same execution path.

Cyera published the four vulnerabilities fixed in OpenClaw as Claw Chain on May 15, 2026. The Hacker News also reported the chain as one that progresses through data theft, privilege escalation, and persistence (the attacker leaving in place a way to come back).
Affected: OpenClaw 2026.4.21 and earlier. Fixed in 2026.4.22.

Response priority

For environments running OpenClaw, this is not a routine library update. It’s a security response that includes an intrusion check.

Item	Decision
Affected	openclaw <= 2026.4.21
Fixed	openclaw >= 2026.4.22
Priority	High for environments using OpenShell, MCP loopback, or Gateway
Entry points	Malicious plugins, prompt injection, poisoned external input, externally exposed OpenClaw servers
Main impact	Secret exfiltration, escalation to owner privileges, Gateway config tampering, cron tampering, persistence
Post-patch action	Inventory and rotate access tokens, API keys, OAuth credentials, bearer tokens

Even after upgrading to openclaw@2026.4.22, treat secrets that may have been read as already compromised.
Rotate environment variables, config files, MCP bearer tokens, and SaaS integration tokens visible to the OpenClaw process separately from the update itself.

The four vulnerabilities

Claw Chain consists of these four CVEs.

CVE	GitHub Advisory	Issue	What the attacker gains
CVE-2026-44112	GHSA-wppj-c6mr-83jj	OpenShell write TOCTOU	Write outside mount root, config tampering, backdoor placement
CVE-2026-44113	GHSA-5h3g-6xhh-rg6p	OpenShell read TOCTOU	Read files, credentials, and internal artifacts outside mount root
CVE-2026-44115	GHSA-x3h8-jrgh-p8jx	Shell expansion inside unquoted heredoc	Leak env vars and tokens while looking like an allowlisted command
CVE-2026-44118	GHSA-r6xh-pqhr-v4xh	MCP loopback owner spoofing	Escalation from a non-owner client to owner-only operations

Cyera scores CVE-2026-44112 as CVSS 9.6 Critical.
GitHub Advisory assigns High or Moderate severity per vulnerability, but looking at individual scores alone misses the main story. The point here is that read, environment variable expansion, privilege escalation, and write all connect on the same agent runtime.

The entry point is not only public-facing servers

Cyera writes that around 65,000 OpenClaw servers are findable on Shodan and around 180,000 on Zoomeye.
These numbers depend on the search conditions, so they don’t translate directly into real asset counts. Still, they show that OpenClaw is not just a small research tool — it’s running widely in places visible from outside.

That said, reading this issue as only “a problem for people who expose OpenClaw to the internet” misses other paths. Claw Chain’s entry surface is wider than network exposure.

Entry	Example
Plugin	Malicious code coming in from ClawHub or internal plugins
Prompt injection	Instructions hidden in email, tickets, chat, issues, web pages. Attacks that steer the agent through external input
External input	External files, repositories, and documents the agent reads
MCP	MCP servers and loopback clients developers wired in experimentally
Internal exposure	Gateways reachable only from internal networks

For AI agents, external input doesn’t stop at “data you only read.” The model interprets the content, calls tools, reads and writes files, and proceeds to internal APIs and MCP.
Compared with classic web apps, prompts, plugins, repos, attachments, and chat history sit much closer to the execution surface.

The Claw Chain flow

Broken down, the chain looks like this.

flowchart TD
    A["Entry<br/>Malicious plugin / prompt injection / poisoned external input"] --> B["Inside OpenShell sandbox<br/>induce code or tool execution"]
    B --> C["CVE-2026-44113<br/>Read outside mount root"]
    B --> D["CVE-2026-44115<br/>Env var expansion inside heredoc"]
    C --> E["Secret harvest<br/>config files / bearer tokens / internal artifacts"]
    D --> E
    E --> F["CVE-2026-44118<br/>MCP loopback owner spoof"]
    F --> G["Owner privilege<br/>Gateway config / cron / execution env management"]
    G --> H["CVE-2026-44112<br/>Write outside mount root"]
    H --> I["Persistence<br/>config tampering / backdoor / changing future agent behavior"]

    style E fill:#7f1d1d,color:#fff
    style I fill:#991b1b,color:#fff

The entry point is one, but partway through several paths work in parallel.
A read TOCTOU pulls files out. A heredoc expansion exposes env vars. The bearer tokens and internal info collected let the attacker cross the MCP loopback owner boundary. Finally a write TOCTOU rewrites the Gateway or execution environment.

Each step is close to OpenClaw’s normal behavior.
Reading files, running commands, calling MCP, touching cron, writing config — none of these are unusual in AI agent operations. For detection, “did a tool get used” is a weaker signal than “did that tool cross its expected boundary.”

OpenShell TOCTOU is a boundary check problem

CVE-2026-44112 and CVE-2026-44113 both break OpenShell’s file boundary through TOCTOU.
TOCTOU stands for Time-of-Check to Time-of-Use — a race condition where the target gets swapped between the check and the actual use.

The specific pattern here: a path inside the workspace looks like it sits inside the mount root when checked, then symlinks point outward by the time it’s actually read or written.

sequenceDiagram
    participant Attacker as Attacker
    participant Agent as OpenClaw/OpenShell
    participant FS as Filesystem

    Attacker->>FS: Prepare a safe-looking path inside mount root
    Agent->>FS: Validate the path
    Attacker->>FS: Swap the symlink after validation
    Agent->>FS: read/write the same path
    FS-->>Agent: Reaches a target outside mount root

The OpenClaw SSH sandbox escape I wrote about in April was also a symlink boundary issue.
That one missed symlink validation during SSH sync. Claw Chain breaks the same way on both the read and write side of OpenShell — the target that was validated and the target that’s actually opened don’t match.

OpenClaw 2026.4.22’s fix shifts away from inspecting path strings, toward validating the opened file descriptor and canonical target against the mount root.
The security boundary now checks “is the object I just opened inside the boundary” instead of “does this string look safe.”

Heredoc is allowlist-bypassing runtime evaluation

CVE-2026-44115 exploits the gap in interpretation between command allowlisting and shell execution.
OpenClaw parses commands to decide whether they’re allowed. But when shell expansion tokens remain in the body of an unquoted heredoc, the string seen at check time and the meaning seen at run time diverge. A heredoc is shell syntax for handing a multi-line string to a command.

The problem is expansions like the following:

cat <<EOF
$TOKEN
$(printenv)
EOF

Even if the allowlist sees “cat is just writing a fixed string,” the shell evaluates $TOKEN and $(...) at run time.
The result: what looks like an approved command becomes an exposure path for environment variables or credentials.

This kind of bug hits AI agent platforms especially hard.
The agent generates command strings. The execution layer inspects them. The shell then evaluates them by yet another set of rules. If those three layers don’t agree on “what is being executed,” the allowlist stops working as a safety boundary.

After the fix, the heredoc body is tracked, and expansion tokens or continuation lines that try to slip through inside an unquoted heredoc are rejected.
This is the same shape as the “don’t blur the tool boundary” point I made in the LLM tool-use API article: the boundary needs to be placed on what the execution layer ultimately evaluates, not the string the model emitted.

MCP loopback is a privilege boundary even on localhost

CVE-2026-44118 lives in the owner check of the MCP loopback runtime.
OpenClaw used senderIsOwner to gate owner-only tools, but the value wasn’t derived from the authenticated session — it was treated as client-controlled metadata. A non-owner loopback client holding a valid bearer token can present itself as the owner.

Once owner privilege is gained, Gateway config, cron scheduling, and execution environment management open up.
This is not just local privilege escalation. Because it can change the agent runtime’s future behavior, it becomes the setup stage for persistence.

In 2026.4.22, owner and non-owner bearer tokens were separated, and senderIsOwner is now derived only from the token used for authentication. The fix is: don’t send or trust a spoofable sender-owner header.

The MCP loopback privilege boundary depends on deciding “whose authority this runs under” from the authentication result rather than from the fact that it’s local-only traffic.
Once an attacker takes code or tool execution inside an AI agent’s process, the loopback client becomes a very convenient internal API for them. The Cursor Git hooks sandbox escape showed the same shape: an ordinary local development mechanism crossed a boundary once combined with autonomous agent execution. The structure here is the same.

What gets taken in a breach

Claw Chain forces you to look beyond OpenClaw’s own configuration.
The scope is anything OpenClaw can see, anything OpenShell can touch, anything an MCP server can act on, and anything reachable from the Gateway configuration.

Asset	Example	Reason
Env vars	API keys, cloud tokens, database URLs, OAuth secrets	Easily exposed through heredoc expansion or file read
Bearer tokens	MCP loopback tokens, Gateway tokens	Used for owner spoofing and internal API operations
Config files	Gateway config, cron, agent config	Write TOCTOU can change future execution
Workspace	Source code, design docs, internal logs	Read escape extends outside the mount root
SaaS integrations	Slack, GitHub, Google Drive, CRM	Data access and operations run with agent permissions
Conversation history	Prompts, outputs, attachments	Easily mixed with corporate or personal data

The most often missed assets are AI agent conversation history and intermediate artifacts.
Security teams are alert to production DBs and AWS keys, but agent-generated temp files, planning notes, review results, and prompts tend to slip under the radar. Claw Chain pulls those operational logs into scope too.

What to look for in logs

Don’t stop at patching — check logs from the period before the patch.
This is not the type of issue where definitive IoCs are published, so detection has to be behavior-based.

Aspect	What to look for
OpenShell file bridge	Symlinks pointing outside mount root, paths created and swapped repeatedly in a short window
Reads	Suspicious access to /etc/, dotfiles in home, credential stores, CI/CD config, cloud config
Writes	Changes to Gateway config, cron, agent startup scripts, plugin directories, MCP config
Exec	Executions containing unquoted heredocs, $TOKEN, $(...), printenv, env, cat <<EOF
MCP loopback	Owner-only tool calls, cron scheduling, execution environment changes, inconsistencies in sender/owner determination
Egress	Traffic to unknown domains, paste sites, object storage, webhooks shortly after agent execution

If logs are thin, don’t be optimistic about recovery.
Any token the OpenClaw agent could read is hard to prove unread. This matches the node-ipc developer secret stealer backdoor situation: closing the entry point and invalidating the keys are separate jobs.

Response steps

The minimum action is updating to openclaw@2026.4.22, but as a security response, go in this order.

Within 24 hours

1. Check package.json, lockfiles, container images, and global installs. Don’t leave any openclaw <= 2026.4.21 behind.
2. Inventory public-facing OpenClaw servers and move them behind auth, VPN, firewall, or reverse proxy.
3. Check whether OpenShell, MCP loopback, Gateway, or plugins are in use.
4. Rotate env vars, bearer tokens, and API keys the OpenClaw process can read.
5. Diff Gateway config, cron, execution environment, and MCP config.

Within a week

1. Inventory the SaaS, repos, filesystem, and secrets each agent touches.
2. Treat the OpenClaw agent as a service account and move it toward least privilege and short-lived tokens.
3. Restrict plugin installation rights and create a review process for ClawHub and internal plugins.
4. Monitor symlinks and out-of-mount-root references inside OpenShell workspaces.
5. Inventory MCP servers and emit owner operations to audit logs.
6. Add egress control and detect agent runtime traffic to unknown external destinations.

Human-in-the-loop (HITL) review adds a layer, but in cases like heredoc expansion or symlink TOCTOU — where the visible command and the actual effect diverge — human review alone is not a reliable boundary.

What’s particular to AI agents

For classic RCE, you check whether the attacker can run a command.
For Claw Chain that’s not enough. OpenClaw itself exists to run commands, manipulate files, call MCP, and integrate with SaaS in the first place.

The attacker doesn’t force OpenClaw into strange behavior from outside. They take over the legitimate capabilities OpenClaw uses every day.
As Cyera points out, the attacker progresses through data access, privilege escalation, and persistence with the agent’s own credentials. Each step looks like “the agent is doing its job.”

This shape also affects how AI agent platforms should be presented to security products and SIEMs.
A process named OpenClaw, traffic to localhost, file operations starting inside a workspace — that combination alone isn’t safe to trust. Audit needs to tie together agent identity, tool boundary, data boundary, and owner operation.

Implications for kana-chat design

kana-chat v3 tones down the do-it-yourself sandbox path that resembled OpenClaw, narrows the stack to wrapping the official Claude Code and Codex CLIs through a tmux bridge, and refocuses the use case on a blog operations pipeline. It doesn’t carry its own OpenShell, its own file sync, or its own MCP owner check. Flexibility goes down, but exposure to the kind of sandbox-boundary swap and owner-check failures that show up in Claw Chain is reduced from the start.

Part of the reason v3 looks like that is that Claude Code and Codex now ship official I/O for driving CLIs from the outside, so the motivation to keep building a tmux wrapper from scratch has thinned out. Rather than pushing toward an OpenClaw-style “delegate everything” platform, narrowing the scope and riding the official CLIs leaves fewer opportunities to be the first one hit by these boundary bugs.

If you’re going to use an OpenClaw-style agent platform in production anyway, design these boundaries in before convenience.

Boundary	What to check in the design
File	Don’t rely on the application’s path-string validation alone
Shell	Validate the meaning the shell evaluates, not the string before it’s handed to the shell
Owner privilege	Derive it from the authenticated token and server-side session, not from a value the client declares
Agent identity	Treat it as an independent privileged identity, not as a human user’s proxy
External input	Audit prompts, plugins, and external input as inputs close to execution

Claw Chain is OpenClaw-specific, but the same shape of thin boundaries shows up across AI agent platforms in general. If you’re going to let an agent touch files, shells, MCP, SaaS, and schedulers, put what it could read, write, escalate to, and persist into your threat model upfront.

References

• The Hacker News: Four OpenClaw Flaws Enable Data Theft, Privilege Escalation, and Persistence
• Cyera: Claw Chain
• OpenClaw Advisory: GHSA-wppj-c6mr-83jj
• OpenClaw Advisory: GHSA-5h3g-6xhh-rg6p
• OpenClaw Advisory: GHSA-r6xh-pqhr-v4xh
• OpenClaw Advisory: GHSA-x3h8-jrgh-p8jx