Insights

OpenClaw MCP Loopback Could Omit sandbox.tools.deny - CVE-2026-100573

Anomity Research Anomity Research · Sep 28, 2026 · 3 min read

TL;DR

CVE-2026-100573 (GitHub advisory GHSA-5m4g-88rg-69pj) is a sandbox policy bypass in OpenClaw before 2026.8.1: MCP loopback could omit the sandbox.tools.deny policy.
A sandboxed coding-agent session could list and invoke tools the operator explicitly denied when MCP loopback was enabled.
GitHub rates this Low at CVSS 3.3 (v3.1). The CVE record also publishes a CVSS 4.0 score of 4.8 (Medium) - do not treat it as Critical.
GitHub advisory published 11 September 2026; CVE record published 26 September 2026. First patched stable release: openclaw@2026.8.1.
The durable lesson is not the CVSS number: config deny lists that are not enforced on every tool path fail. Runtime allow/deny/log at the agent hook is the backstop.

Sandbox deny lists are comforting until a code path forgets them. CVE-2026-100573 / GHSA-5m4g-88rg-69pj is a Low-severity OpenClaw issue with a sharp lesson: when MCP loopback omitted sandbox.tools.deny, sandboxed coding-agent sessions could still list and invoke tools operators thought they had excluded. Fixed in 2026.8.1. CVE record published 26 September 2026.

What OpenClaw disclosed

Per GHSA-5m4g-88rg-69pj (published 11 September 2026), affected openclaw versions are below 2026.8.1. In those builds, the bundled MCP loopback used by sandboxed coding-agent sessions could omit the sandbox tool deny policy. A session that should have been constrained by sandbox.tools.deny could still discover and call denied tools. Practical impact depends on which tools were denied and what capabilities those tools held.

Severity stays honest: GitHub rates Low at CVSS 3.3. The CVE entry also carries a CVSS 4.0 score of 4.8 (Medium). Neither number makes this a fleet-wide Critical. The advisory also scopes trust carefully - authenticated Gateway operators and intentional local surfaces remain in OpenClaw's trusted-operator model unless another boundary is crossed. That scoping is why this piece is Insights, not a severity-inflated Advisory.

Mitigations from the advisory: upgrade to openclaw@2026.8.1 or later; until then, disable MCP loopback for sandboxed coding agents or remove sensitive tools from the Gateway inventory. OpenClaw already sits in Anomity's corpus for supply-chain and exposure themes - see OpenClaw 2.0 security skill supply chain and the earlier OpenClaw security crisis / ClawHavoc coverage.

Why deny lists fail without invocation-time checks

A deny list only works if every path that can list or invoke tools consults it. MCP loopback is exactly the kind of alternate path that gets added for convenience and reviewed as "still inside the sandbox." When the deny policy is omitted on that path, the config file still looks correct in screenshots and policy reviews - the session just does not obey it.

That is the same structural gap we document for coding-agent sandboxes elsewhere: OpenAI Codex separates sandbox mode from approval policy, and neither dial alone tells security what ran on a laptop last Tuesday (Codex sandbox and approval model; securing Codex sandbox and approvals). Permission models across Claude Code, Codex, and Cursor are real per-machine controls (comparison) - they still need a fleet layer that evaluates the tool call before it executes.

Enterprise framing also shows up in containment research: identity without isolation leaves agents holding powerful tokens inside weak process boundaries (AI agent containment gap). A sandbox deny list that a loopback path skips is containment theater - least privilege for AI agents only holds if enforcement is on the hot path.

What to change in governance

Upgrade OpenClaw to 2026.8.1+ and verify MCP loopback behavior against your sandbox.tools.deny list with a deliberate denied-tool probe.
Treat every MCP entry path as a policy surface - loopback, remote HTTP, STDIO bridges - not only the primary agent UI.
Inventory which endpoints run OpenClaw (and which MCP servers those sessions can reach), including developer laptops that never filed a ticket.
Enforce at invocation: allow/deny/log on the agent hook so a forgotten product deny list is not your only control.
Keep an audit trail of denied and allowed tool calls so "we thought that tool was blocked" is answerable from logs.

How Anomity enforces what deny lists intend

Anomity's Endpoint Sensor inventories agents, MCPs, extensions, plugins, skills, hooks, and related artifacts on managed endpoints. Browser Sensor and cloud discovery (Google Workspace / GitHub OAuth grants) cover adjacent AI use. Metadata only; secrets are redacted on-endpoint.

On agents that expose a hook such as Claude Code PreToolUse, runtime governance returns allow, deny, or log before a tool call runs. That decision does not depend on whether a product sandbox remembered sandbox.tools.deny on every MCP loopback path. Outcomes land in a 90-day audit trail and route to SIEM, Slack, email, or Jira. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC.

CVE-2026-100573 is Low severity and still worth a patch - because it shows how quickly a reviewed deny list becomes fiction on an alternate tool path. See the denied tool, deny it at the hook, keep the record. Book a 30-minute demo.

Frequently asked questions

What is CVE-2026-100573 in OpenClaw?

CVE-2026-100573 is a sandbox policy bypass tracked as GHSA-5m4g-88rg-69pj. In OpenClaw versions before 2026.8.1, the bundled MCP loopback used by sandboxed coding-agent sessions could omit the sandbox.tools.deny policy, so a sandboxed session could list and invoke tools the operator had explicitly denied.

How severe is it?

GitHub's advisory severity is Low with CVSS 3.1 score 3.3 (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). The CVE record also lists a CVSS 4.0 base score of 4.8 (Medium). Practical impact depends on which tools were denied and what those tools can do. This is not a remote unauthenticated Critical - do not inflate it.

What is in scope for the advisory?

The advisory is scoped to the bundled MCP loopback used by sandboxed coding-agent sessions. It does not rewrite OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

How do I fix or mitigate it?

Upgrade to openclaw@2026.8.1 or later. Until you can upgrade, disable MCP loopback for sandboxed coding agents or remove sensitive tools from the Gateway inventory so a bypassed deny list has less to reach.

Why does this matter if severity is Low?

Because enterprises keep buying the story that a sandbox deny list is the control. When one tool path (here, MCP loopback) forgets to apply that list, the session's effective policy diverges from the config operators reviewed. Low severity still teaches a high-frequency failure mode: policy that is not evaluated at invocation time is documentation, not enforcement.

How does Anomity help with sandbox deny drift?

Anomity inventories agents, MCPs, and related artifacts on managed endpoints via the Endpoint Sensor, with Browser Sensor and cloud discovery for adjacent surfaces. On agents that expose a hook, runtime governance returns allow, deny, or log before a tool call runs - independent of whether a product sandbox remembered its deny list on every loopback path. Decisions land in a 90-day audit trail routed to SIEM, Slack, email, or Jira.