OpenClaw's SSH sandbox can be escaped through a symlink, CVSS 8.8
Contents
OpenClaw has another sandbox hole. GHSA-fv94-qvg8-xqpw, CVSS 8.8. The file synchronization step in the SSH sandbox did not validate symbolic links, which means an AI agent could read or write arbitrary files outside the sandbox. Affected versions are OpenClaw 2026.3.28 and earlier. The bug was fixed in 2026.3.31. A proof of concept is already public at an academic level.
I wrote “another” because this is not the first OpenClaw sandbox issue. CVE-2026-27522 was a sandbox escape via path traversal, and GHSA-m8v2-6wwh fixed another sandbox escape through symlink manipulation. The pattern is clear: boundary checks keep getting broken.
How the Vulnerability Works
The problem is in uploadDirectoryToSshTarget. That function uploads the local working directory to the SSH sandbox, but it had no validation for symlinks inside the file tree.
graph TD
A["Attacker uses prompt injection<br/>to tell the AI agent to create a symlink"] --> B["Symlink is created inside the workspace"]
B --> C["ln -s /etc/passwd workspace/link"]
C --> D["uploadDirectoryToSshTarget<br/>processes the symlink without validation"]
D --> E["Follows the symlink and reads<br/>files outside the sandbox"]
D --> F["Follows the symlink and writes<br/>to arbitrary paths on the remote host"]
E --> G["Steal secrets, config files,<br/>and credentials"]
F --> H["Tamper with system files on the remote host"]
style G fill:#991b1b,color:#fff
style H fill:#991b1b,color:#fffThe attack vector is either network-based or prompt injection against the AI agent. If the attacker can get the agent to create a symlink, they can pivot from there to arbitrary file access.
CWE Classification
Two CWEs were assigned to this issue.
| CWE | Name | Meaning |
|---|---|---|
| CWE-61 | UNIX Symbolic Link Following | The program follows a symlink and reaches a file it should not access |
| CWE-59 | Improper Link Resolution Before File Access | Link targets are not resolved properly before file access |
CWE-61 is the classic UNIX symlink attack pattern. CWE-59 is broader and covers improper link resolution in general, including hard links and junction points.
In OpenClaw’s case, there was not even a race condition to exploit. The validation simply did not exist. The check phase was missing entirely.
The Fix
Commit 3d5af14 added assertSafeUploadSymlinks. It uses fs.readdir({ withFileTypes: true }) to inspect the directory entries, then calls resolveBoundaryPath to make sure any symlink target stays within the sandbox boundary. If a symlink points outside the boundary, the upload is rejected.
The fix looks like this:
| Item | Before | After |
|---|---|---|
| Symlink detection | None | fs.readdir({ withFileTypes: true }) |
| Link-target validation | None | Boundary check with resolveBoundaryPath |
| Out-of-bound symlinks | Followed as-is | Upload rejected |
That said, this is still just upload-time validation. Anthropic’s Python SDK had a similar symlink race condition (CVE-2026-34452), where a symlink could be swapped in between path validation and the actual file operation. Whether OpenClaw’s fix survives that class of race depends on whether assertSafeUploadSymlinks runs atomically with the file open.
OpenClaw’s Sandbox Attack History
OpenClaw’s security issues started with SkillHub supply-chain and prompt-injection problems, then moved on to NemoClaw trying to defend with four layers of sandboxing. This latest bug is different: it is a flaw in the sandbox implementation itself. No matter how much you stack on top, if the file sync layer lets symlinks through, the foundation is weak.
Here is the timeline of OpenClaw security issues I have covered:
| Time | Attack / vulnerability | Method |
|---|---|---|
| February | AMOS distributed through SKILL.md | A malicious skill used the AI as a bridge to install macOS malware |
| February | 7.1% of SkillHub vulnerable | 30,000 exposed instances, OAuth tokens stored in plaintext |
| March | CVE-2026-27522 | Sandbox escape via path traversal |
| March | CVE-2026-25253 | RCE via gatewayUrl (CVSS 8.8) |
| March | GHSA-m8v2-6wwh | Sandbox escape through symlink manipulation |
| April | GHSA-fv94-qvg8-xqpw (this issue) | Missing symlink validation during SSH sync |
This is already the third sandbox escape. Different path, same root cause: weak boundary checks.
Impact and Mitigations
Affected systems are all OpenClaw versions up to 2026.3.28, especially Node.js environments using the openclaw npm package and connecting to a remote SSH sandbox.
The fix is to update openclaw in package.json to >=2026.3.31 and run npm update openclaw. The advisory also recommends the following mitigations:
- Enable HITL (Human-in-the-Loop) mode so a person reviews the agent’s file operations
- Apply least privilege to the SSH sandbox user account
- Monitor the local agent workspace for suspicious symlink creation
OS-level isolation like macOS sandbox-exec or Windows Sandbox blocks system calls in the kernel, which is a different defense layer from application-level validation. OpenClaw’s SSH sandbox depends on application-level boundary checks, so a missed check turns directly into a sandbox escape.
The Gap Between Ecosystem Growth and CVEs
The OpenClaw ecosystem is still expanding quickly. NVIDIA is shipping NemoClaw with four layers of sandboxing so enterprises can use OpenClaw agents more safely. Manus is also building OpenClaw-compatible agent infrastructure and hosting its own sandboxed environment. The “easy-to-deploy agents” world is getting closer.
At the same time, the last two months produced three sandbox escapes and four Critical-to-High issues if you include RCE. Add the skill-supply-chain problem and plaintext OAuth tokens, and the security incident density is high. Ecosystem growth is outrunning security maturity.
The structural problem is that OpenClaw’s sandbox leans entirely on application-level boundary checks. Unlike kernel-level isolation such as macOS sandbox-exec, Linux seccomp/namespaces, or gVisor, one validation bug is enough to defeat the sandbox. NemoClaw’s four-layer defense is trying to patch over that weakness, but if the base layer keeps leaking, the stack still wobbles.
NVIDIA and Manus entering the space is good for the ecosystem, and NemoClaw could improve the situation by putting OS-level sandboxing under OpenClaw. But at the moment, the design still assumes that OpenClaw’s own sandbox can be trusted. Until the ecosystem assumes validation bugs will happen and bakes in multiple layers of defense, the same class of vulnerability will keep coming back.
If you want to run OpenClaw in production, do not rely only on its sandbox. Add OS-level isolation and strict network segmentation on top of it. At this point, “the official sandbox says it is safe” is not a mature security posture.
People who come in through NemoClaw or Manus may not even know they are standing on OpenClaw. When the wrapper hides the underlying component, it becomes easy to trust the whole stack just because NVIDIA shipped it. But the fact remains: your agent is running on top of something that has already produced four High-or-worse issues in two months.
I built Kana Chat to avoid this exact structure. Kana Chat wraps the official Claude Code CLI over a tmux bridge, with no custom file sync and no SSH sandbox at all. It rides the CLI’s own permission model and keeps Kana Chat itself at the orchestration layer. It is less flexible than OpenClaw, but it also means I am not writing my own symlink validator only to patch it after the next escape.