GHSA-qh2f-99mv-mrcf: OpenClaw exec denylist bypass

Q: Is GHSA-qh2f-99mv-mrcf actively exploited?

No confirmed active exploitation of GHSA-qh2f-99mv-mrcf has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-qh2f-99mv-mrcf?

Upgrade to OpenClaw 2026.5.12 or later, where the denylist is correctly enforced on session spawn. Until patched: restrict bundled MCP loopback access to trusted operators only; disable the affected feature entirely if it isn't in active use; keep channel and tool allowlists as narrow as possible; and never share a single Gateway instance between mutually untrusted users. For detection, audit Gateway configuration for loopback MCP exposure, review session-spawn logs for commands that should have been denylisted, and monitor for anomalous process execution originating from MCP session-spawn events. Since there's no CVSS/EPSS signal to prioritize against, treat patch timing as driven by exposure (is the loopback feature enabled and reachable by lower-trust callers?) rather than by external exploitation telemetry.

Q: What systems are affected by GHSA-qh2f-99mv-mrcf?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool integration, multi-tenant agent gateways.

Q: What is the CVSS score for GHSA-qh2f-99mv-mrcf?

No CVSS score has been assigned yet.

CISO Take

OpenClaw's bundled MCP loopback entry point could be reached without enforcing the exec denylist meant to restrict it, letting a session spawn with broader command reach than that integration path was designed to allow. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template published, so this isn't being actively weaponized today — but the underlying weakness (CWE-78 OS command injection plus CWE-284 improper access control) sits directly in an agent's command-execution surface, which is a high-consequence place for a control gap. The vendor is explicit that this doesn't break the trusted-operator model — it matters when a lower-trust caller (another user on a shared Gateway, or an untrusted plugin) can reach the loopback path. Patch to 2026.5.12 now; until then, restrict bundled MCP loopback access to trusted operators only, keep tool/channel allowlists narrow, and don't share one Gateway between mutually untrusted users. Downstream dependents are limited (4), which caps blast radius, but any org running OpenClaw as a shared agent gateway should treat this as a same-week patch, not a backlog item.

Sources: GitHub Advisory ATLAS

What is the risk?

Medium severity as rated by the advisory, with no CVSS vector, no EPSS score, and no evidence of active exploitation (not in CISA KEV, no public PoC, no Nuclei template). That keeps near-term opportunistic risk low. However, the vulnerability class — an access-control gap (CWE-284) that permits OS command injection (CWE-78) — is severe by nature because it lives in the exec path of an AI agent runtime, where successful exploitation converts directly into command execution with elevated reach. The vendor's advisory scopes this narrowly (it does not affect the general trusted-operator model), so real-world risk is highly configuration-dependent: it only matters where the bundled MCP loopback feature is enabled, reachable, and shared across parties with differing trust levels (e.g., a multi-tenant Gateway). Downstream package exposure is small (4 dependents), limiting supply-chain-style blast radius, but the package has a long history of prior CVEs (400 in the same package), suggesting a broader pattern of security debt worth tracking.

How does the attack unfold?

Reach loopback entry point

A caller with access to the bundled MCP loopback — e.g., another user on a shared Gateway or a lower-trust plugin — reaches the affected session-spawn path.

AML.T0053

Denylist bypass on session spawn

The exec denylist intended to restrict that loopback entry point is not enforced when the new session is created, evading the intended defense.

AML.T0107

Broader command execution

The spawned session gains command reach beyond the MCP path's intended scope, enabling OS command execution (CWE-78).

AML.T0050

Impact

Depending on operator configuration, the attacker executes commands with the loopback session's trust level, potentially compromising the host running OpenClaw.

AML.T0112

Reach loopback entry point

A caller with access to the bundled MCP loopback — e.g., another user on a shared Gateway or a lower-trust plugin — reaches the affected session-spawn path.

AML.T0053

Denylist bypass on session spawn

The exec denylist intended to restrict that loopback entry point is not enforced when the new session is created, evading the intended defense.

AML.T0107

Broader command execution

The spawned session gains command reach beyond the MCP path's intended scope, enabling OS command execution (CWE-78).

AML.T0050

Impact

Depending on operator configuration, the attacker executes commands with the loopback session's trust level, potentially compromising the host running OpenClaw.

AML.T0112

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
OpenClaw	npm	< 2026.5.12	`2026.5.12`
3 dependents 37% patched ~3d to patch Full package profile →

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1

N/A

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What should I do?

1 step

Upgrade to OpenClaw 2026.5.12 or later, where the denylist is correctly enforced on session spawn. Until patched: restrict bundled MCP loopback access to trusted operators only; disable the affected feature entirely if it isn't in active use; keep channel and tool allowlists as narrow as possible; and never share a single Gateway instance between mutually untrusted users. For detection, audit Gateway configuration for loopback MCP exposure, review session-spawn logs for commands that should have been denylisted, and monitor for anomalous process execution originating from MCP session-spawn events. Since there's no CVSS/EPSS signal to prioritize against, treat patch timing as driven by exposure (is the loopback feature enabled and reachable by lower-trust callers?) rather than by external exploitation telemetry.

How is it classified?

Auth Bypass Code Execution Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0053 - AI Agent Tool Invocation AML.T0107 - Exploitation for Defense Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.6 - AI system operational security controls

OWASP LLM Top 10

LLM07 - Insecure Plugin Design LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-qh2f-99mv-mrcf?

OpenClaw's bundled MCP loopback entry point could be reached without enforcing the exec denylist meant to restrict it, letting a session spawn with broader command reach than that integration path was designed to allow. There's no CVSS score, no EPSS data, no CISA KEV listing, and no public exploit or Nuclei template published, so this isn't being actively weaponized today — but the underlying weakness (CWE-78 OS command injection plus CWE-284 improper access control) sits directly in an agent's command-execution surface, which is a high-consequence place for a control gap. The vendor is explicit that this doesn't break the trusted-operator model — it matters when a lower-trust caller (another user on a shared Gateway, or an untrusted plugin) can reach the loopback path. Patch to 2026.5.12 now; until then, restrict bundled MCP loopback access to trusted operators only, keep tool/channel allowlists narrow, and don't share one Gateway between mutually untrusted users. Downstream dependents are limited (4), which caps blast radius, but any org running OpenClaw as a shared agent gateway should treat this as a same-week patch, not a backlog item.

Is GHSA-qh2f-99mv-mrcf actively exploited?

No confirmed active exploitation of GHSA-qh2f-99mv-mrcf has been reported, but organizations should still patch proactively.

How to fix GHSA-qh2f-99mv-mrcf?

Upgrade to OpenClaw 2026.5.12 or later, where the denylist is correctly enforced on session spawn. Until patched: restrict bundled MCP loopback access to trusted operators only; disable the affected feature entirely if it isn't in active use; keep channel and tool allowlists as narrow as possible; and never share a single Gateway instance between mutually untrusted users. For detection, audit Gateway configuration for loopback MCP exposure, review session-spawn logs for commands that should have been denylisted, and monitor for anomalous process execution originating from MCP session-spawn events. Since there's no CVSS/EPSS signal to prioritize against, treat patch timing as driven by exposure (is the loopback feature enabled and reachable by lower-trust callers?) rather than by external exploitation telemetry.

What systems are affected by GHSA-qh2f-99mv-mrcf?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, MCP tool integration, multi-tenant agent gateways.

What is the CVSS score for GHSA-qh2f-99mv-mrcf?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

agent frameworksMCP tool integrationmulti-tenant agent gateways

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0053 AI Agent Tool Invocation

AML.T0107 Exploitation for Defense Evasion

Compliance Controls Affected

ISO 42001: A.6.2.6

OWASP LLM Top 10: LLM07, LLM08

What are the technical details?

Original Advisory

### Summary Bundle MCP loopback could miss its exec denylist on session spawn. In affected versions, a caller that can reach the affected bundled MCP session-spawn path could bypass the denylist that was intended for that loopback MCP entry point. This advisory is scoped to the named feature and configuration. It does not change 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. ### Impact When the affected feature is enabled and reachable, this could start a session with broader command reach than that MCP path should provide. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path. ### Patched Versions The first stable patched version is `2026.5.12`. ### Mitigations restrict bundled MCP loopback access to trusted operators until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Exploitation Scenario

An organization runs a shared OpenClaw Gateway serving multiple users or hosting a mix of trusted and less-trusted plugins, with the bundled MCP loopback feature enabled for convenience. A lower-trust caller — another user on that Gateway, or a plugin with limited intended scope — reaches the loopback MCP session-spawn path. Because the exec denylist isn't enforced at that spawn point in unpatched versions, the resulting session inherits broader command execution reach than the MCP integration was designed to provide. The caller uses that unintended reach to run OS commands (CWE-78) outside the boundary the denylist was meant to enforce, potentially pivoting from the agent process to broader host access depending on how the operator has otherwise sandboxed the deployment.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary CWE-78 Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection') Primary

CWE-284 — Improper Access Control: The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.

[Architecture and Design, Operation] Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.

Source: MITRE CWE corpus.