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.
| Score | Percentile |
|---|---|
| 0.01% | 1.49% |
| Base score | Version | Severity | Vector |
|---|---|---|---|
| 6.1 | 3.1 | — |
|
| 5.8 | 4.0 | — |
|
| Type | Value |
|---|---|
| GHSA | GHSA-9q36-67vc-rrwg ↗ |
| CVE | CVE-2026-27646 ↗ |
Vulnerable version ranges and first patched releases as published by GitHub.
| Ecosystem | Package | Vulnerable range | First patched | Vulnerable functions |
|---|---|---|---|---|
| npm | openclaw | <= 2026.3.2 | 2026.3.7 | — |