OpenClaw users face a high-severity vulnerability that lets attackers bypass the gateway’s exec allowlist using /usr/bin/script wrappers. If you run versions up to 2026.3.24, update to 2026.3.28 or later right now. The flaw persists “allow-always” trust decisions on wrappers without checking the underlying commands they execute.
This issue hits the core of OpenClaw’s security model. OpenClaw acts as a dispatch and execution wrapper enforcer, typically in Linux environments, to whitelist approved binaries and scripts. It prompts users for one-time or persistent approval on unknown executions. The “allow-always” option stores trust for future runs. But through commit 83da3cfe31, developers fixed a gap: the system stored trust for the wrapper binary itself, like /usr/bin/script, instead of resolving and trusting the actual target command inside it.
Technical Breakdown
Consider /usr/bin/script, a standard Unix utility that spawns a shell, runs a command, and logs the tty session to a file. An attacker approves script -c "cat /etc/passwd" logfile, which OpenClaw sees as executing /usr/bin/script. The persistence trusts script indefinitely.
Later, the same wrapper runs script -c "rm -rf /important/data" logfile. OpenClaw skips checks because /usr/bin/script is already whitelisted. No prompt, no block. The affected code lives in src/infra/dispatch-wrapper-resolution.ts and src/infra/exec-wrapper-resolution.ts, where resolution logic failed to recursively unwrap nested executions.
This isn’t unique to script. Tools like sudo, expect, or custom shell scripts suffer the same. OpenClaw’s trust model assumes direct binary execution, but real-world chains expose this blind spot. Patched versions, from 2026.3.28, add proper unwrapping via the named commit: “infra: unwrap script wrapper approval targets.” Developers shipped the fix fast—four days from 2026.3.24—showing solid response, but the window existed.
Why This Matters and What to Do
In high-stakes setups—think servers, CI/CD pipelines, or air-gapped systems—OpenClaw enforces least-privilege execution. A single misplaced approval turns persistent trust into a backdoor. Attackers with shell access (say, via phishing or vuln exploit) chain benign approvals to escalate. Imagine a dev approving a logging script; ops later runs a payload under the same wrapper. Data loss, ransomware deployment, or lateral movement follows.
Quantify the risk: CVSS isn’t scored here, but “HIGH” flags it. Affected versions span recent stables up to 2026.3.24. If you’re on <=2026.3.24, exposure is live. No public exploits yet, but script wrappers are low-hanging fruit for red teams. Similar issues plague SELinux, AppArmor, or grsecurity exec policies when they overlook shebangs and argv[0] tricks.
Update to 2026.3.28 immediately. Verify with
git log --oneline | grep 83da3cfe31 or check the tag. Audit logs for /usr/bin/script approvals post-approval. Revoke suspicious allow-always entries via OpenClaw’s admin interface. Test in staging: approve a safe script-wrapped command, then swap to a risky one, confirm blocking.
Beyond the patch, harden your setup. Disable allow-always for wrappers entirely, or configure stricter path resolution. Pair OpenClaw with syscall monitoring like auditd:
auditctl -a always,exit -F arch=b64 -S execve -k exec_watch. In crypto ops or finance nodes, where one bad exec wipes keys, this vuln underscores wrapper hell—systems must resolve full execution graphs, not surface binaries.
Fair take: OpenClaw’s model is sound for controlled envs, and quick patching builds trust. But it exposes a systemic challenge in allowlisting: dynamic execution defies static rules. Watch for regressions; test wrappers rigorously. If you’re building similar tools, bake in argv expansion from day one.
