Sandboxed requester sessions could reach host-side ACP session initialization through /acp spawn.
OpenClaw already blocked sessions_spawn({ runtime: "acp" }) from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first.
openclaw<= 2026.3.2>= 2026.3.7ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in src/agents/acp-spawn.ts already denied sandboxed requesters, but /acp spawn in src/auto-reply/reply/commands-acp/lifecycle.ts called initializeSession(...) without first applying the same restriction.
In affected versions, an already authorized sender in a sandboxed session could use /acp spawn to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available.
61000b8e4ded919ca1a825d4700db4cb3fdc56e3The fix introduced a shared ACP runtime-policy guard in src/agents/acp-spawn.ts and reused it from the /acp spawn handler in src/auto-reply/reply/commands-acp/lifecycle.ts before any ACP backend initialization. Regression coverage was added in src/auto-reply/reply/commands-acp.test.ts to prove sandboxed /acp spawn requests are rejected early, while existing ACP spawn behavior for non-sandboxed sessions remains unchanged.
Patched version is pre-set to 2026.3.7 so the advisory can be published once that npm release is available.
Thanks @tdjackey for reporting.
{
"cwe_ids": [
"CWE-284",
"CWE-693",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-09T19:54:54Z",
"nvd_published_at": "2026-03-23T22:16:25Z",
"severity": "MODERATE"
}