GHSA-xmv6-r34m-62p4 — openclaw
Fix: openclaw/openclaw@496a76cGHSA-xmv6-r34m-62p4 is a security vulnerability in openclaw. A fix is available for openclaw — see the affected versions and patch details below.
OpenClaw: Sandbox media fallback tmp symlink alias bypass allows host file reads outside sandboxRoot
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
openclawnpmDescription
Summary
A sandbox path validation bypass in openclaw allows host file reads outside sandboxRoot via the media path fallback tmp flow when the fallback tmp root is a symlink alias.
Affected Packages / Versions
- Package:
npm openclaw - Affected versions:
<= 2026.2.24 - Latest published npm version at triage time (February 26, 2026):
2026.2.24 - Patched version :
2026.2.25
Details
When /tmp/openclaw is unavailable or unsafe, resolvePreferredOpenClawTmpDir() in src/infra/tmp-openclaw-dir.ts fell back to os.tmpdir()/openclaw-<uid> without verifying that fallback path was a trusted non-symlink directory.
resolveSandboxedMediaSource() (src/agents/sandbox-paths.ts) allows absolute tmp media paths under the OpenClaw tmp root using lexical containment and alias checks. If the fallback tmp root is a symlink alias (for example to /), inputs like $TMPDIR/openclaw-<uid>/etc/passwd can pass validation and resolve to host files outside sandboxRoot.
Impact
This can break sandbox media path confinement and permit unauthorized host file reads (confidentiality impact).
Reproduction (high level)
- Force resolver fallback (make
/tmp/openclawunavailable/invalid). - Make fallback root (
$TMPDIR/openclaw-<uid>) a symlink alias to/. - Submit media path under fallback root (for example
$TMPDIR/openclaw-<uid>/etc/passwd). - Observe accepted path and read outside
sandboxRoot.
Fix Commit(s)
496a76c03ba85e15ea715e5a583e498ae04d36e3
Release Process Note
Patched version is pre-set to release 2026.2.25; once npm publish for 2026.2.25 is complete, this advisory can be published without further metadata edits.
OpenClaw thanks @tdjackey for reporting.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | openclaw | all versions | 2026.2.25npm install openclaw@2026.2.25 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for openclaw, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update openclaw to 2026.2.25 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-xmv6-r34m-62p4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-xmv6-r34m-62p4 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-xmv6-r34m-62p4. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-xmv6-r34m-62p4 in your dependencies?
O3 Security finds GHSA-xmv6-r34m-62p4 across npm dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.