GHSA-mhq8-78pj-5j79: OpenClaw: safe-bin bypass exposes node-local files

GHSA-mhq8-78pj-5j79 HIGH
Published July 2, 2026
CISO Take

OpenClaw's system.run tool let an authenticated operator or agent flow bypass its safe-bin allowlist by exploiting POSIX shell expansion, so a command that looked pre-approved could resolve into extra shell words and read a node-local file the policy never intended to expose. This isn't a background scanning target: there's no public exploit, no Nuclei template, it isn't in CISA's KEV, and EPSS data isn't available, so opportunistic mass exploitation is unlikely today — but the CVSS 7.1 score (AC:H, PR:L, C:H/I:H) reflects real confidentiality and integrity impact once a lower-privileged operator or automated agent flow reaches the tool. With only 4 tracked downstream dependents the blast radius is currently narrow, but openclaw itself carries 425 other CVEs, signaling a package with a broad and recurring attack surface that deserves ongoing scrutiny rather than a one-off patch. Any deployment pairing a POSIX node to the gateway with safe-bin or allowlist-based auto-approval on system.run should treat this as a policy-enforcement gap, not just a code bug. Patch to openclaw 2026.5.18 or later immediately, and until then disable broad safe-bin auto-approval for commands whose arguments can be shell-expanded, requiring explicit human approval for any system.run call that touches local files.

Sources: GitHub Advisory ATLAS CISA KEV

What is the risk?

Exploitability is constrained by design: the flaw requires an already-authenticated operator or agent-driven flow with PR:L access to a paired POSIX node, plus a specific configuration (safe-bin/allowlist auto-approval on system.run) that changes attacker cost from 'unauthenticated internet-wide' to 'insider or compromised low-privilege session.' The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L) rates high attack complexity but high confidentiality and integrity impact, and the absence of EPSS scoring, KEV listing, public PoCs, or Nuclei templates suggests no observed opportunistic exploitation yet. Overall risk should be rated 'high but contained' — real impact if reachable, low probability of drive-by exploitation, and directly tied to how permissively an organization configures OpenClaw's auto-approval policy.

How does the attack unfold?

Initial Access
An authenticated operator or agent flow with low privileges gains reach to the system.run tool on a POSIX node paired to the gateway.
AML.T0053
Policy Bypass via Shell Expansion
A safe-bin-approved command is submitted whose argument, once expanded by the POSIX shell (globbing, word splitting, substitution), resolves into additional shell words after approval already occurred.
AML.T0050
Unintended File Read
The expanded argv causes the approved binary to operate on a node-local file outside the policy's intent, such as OpenClaw configuration.
AML.T0037
Disclosure Impact
Output is returned through the same operator/agent channel that issued the original command, exposing node-local configuration or other sensitive data without raising a distinct policy-violation flag.

What systems are affected?

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

Do you use OpenClaw? You're affected.

How severe is it?

CVSS 3.1
7.1 / 10
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC High
PR Low
UI None
S Unchanged
C High
I High
A Low

What should I do?

1 step
  1. 1) Upgrade to openclaw 2026.5.18 or later, which fixes the argv-validation gap. 2) Until patched, disable or narrow safe-bin/allowlist auto-approval for any system.run command whose arguments are subject to shell expansion (globs, variable expansion, command substitution) — require explicit human approval instead. 3) Audit exec policy configs on all paired POSIX nodes for allowlist entries that could read arbitrary paths. 4) Add detection for system.run invocations where the executed argv differs from the approved/logged command string — the tell-tale sign of this bypass class. 5) Rotate any node-local secrets/config that could plausibly have been exposed if this auto-approval pattern was in use pre-patch.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act
Article 15 - Accuracy, Robustness and Cybersecurity
ISO 42001
A.6.2.6 - AI system operation and monitoring
NIST AI RMF
MEASURE 2.7 - AI system security and resilience are evaluated and documented
OWASP LLM Top 10
LLM06:2025 - Excessive Agency

Frequently Asked Questions

What is GHSA-mhq8-78pj-5j79?

OpenClaw's system.run tool let an authenticated operator or agent flow bypass its safe-bin allowlist by exploiting POSIX shell expansion, so a command that looked pre-approved could resolve into extra shell words and read a node-local file the policy never intended to expose. This isn't a background scanning target: there's no public exploit, no Nuclei template, it isn't in CISA's KEV, and EPSS data isn't available, so opportunistic mass exploitation is unlikely today — but the CVSS 7.1 score (AC:H, PR:L, C:H/I:H) reflects real confidentiality and integrity impact once a lower-privileged operator or automated agent flow reaches the tool. With only 4 tracked downstream dependents the blast radius is currently narrow, but openclaw itself carries 425 other CVEs, signaling a package with a broad and recurring attack surface that deserves ongoing scrutiny rather than a one-off patch. Any deployment pairing a POSIX node to the gateway with safe-bin or allowlist-based auto-approval on system.run should treat this as a policy-enforcement gap, not just a code bug. Patch to openclaw 2026.5.18 or later immediately, and until then disable broad safe-bin auto-approval for commands whose arguments can be shell-expanded, requiring explicit human approval for any system.run call that touches local files.

Is GHSA-mhq8-78pj-5j79 actively exploited?

No confirmed active exploitation of GHSA-mhq8-78pj-5j79 has been reported, but organizations should still patch proactively.

How to fix GHSA-mhq8-78pj-5j79?

1) Upgrade to openclaw 2026.5.18 or later, which fixes the argv-validation gap. 2) Until patched, disable or narrow safe-bin/allowlist auto-approval for any system.run command whose arguments are subject to shell expansion (globs, variable expansion, command substitution) — require explicit human approval instead. 3) Audit exec policy configs on all paired POSIX nodes for allowlist entries that could read arbitrary paths. 4) Add detection for system.run invocations where the executed argv differs from the approved/logged command string — the tell-tale sign of this bypass class. 5) Rotate any node-local secrets/config that could plausibly have been exposed if this auto-approval pattern was in use pre-patch.

What systems are affected by GHSA-mhq8-78pj-5j79?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool invocation, distributed/paired agent node execution.

What is the CVSS score for GHSA-mhq8-78pj-5j79?

GHSA-mhq8-78pj-5j79 has a CVSS v3.1 base score of 7.1 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworksAI agent tool invocationdistributed/paired agent node execution

MITRE ATLAS Techniques

AML.T0037 Data from Local System
AML.T0050 Command and Scripting Interpreter
AML.T0053 AI Agent Tool Invocation
AML.T0083 Credentials from AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15
ISO 42001: A.6.2.6
NIST AI RMF: MEASURE 2.7
OWASP LLM Top 10: LLM06:2025

What are the technical details?

Original Advisory

### Summary On POSIX nodes, OpenClaw's `system.run` safe-bin checks could approve a command before shell expansion changed how the command was interpreted. A value that appeared to be a safe-bin argument could expand into additional shell words and become a file operand. This issue is limited to paired POSIX node execution through `system.run` with safe-bin or allowlist-style auto-approval. It is not an unauthenticated node takeover. ### Affected configurations This affects deployments where: - a POSIX node is paired to the gateway - `system.run` is reachable by an authenticated operator or agent flow - exec policy uses safe-bin or allowlist-based auto-approval - the approved command contains shell-expanded values that can change argv shape ### Impact A lower-privilege operator flow could cause an approved safe-bin command to read a node-local file that was not intended by the policy. Depending on the local files available to the node process, this could expose OpenClaw configuration data or other node-local information. The issue is a policy-enforcement gap in argv validation, not a general statement that every safe-bin command is unsafe. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations Upgrade to `openclaw@2026.5.18` or later. Before upgrading, avoid broad safe-bin auto-approval for commands that can read arbitrary paths, and prefer explicit approval for node commands that touch local files.

Exploitation Scenario

A lower-privileged operator, or an automated agent flow acting on their behalf, submits a system.run request using a safe-bin command that the exec policy pre-approves based on its literal text (e.g., an allowlisted binary plus what looks like a benign argument). On the POSIX node, the shell expands that argument — via globbing, word splitting, or variable substitution — before execution, turning it into additional shell words that the approved binary treats as a new file operand. The binary then reads a node-local file never intended by the policy (such as OpenClaw's own configuration), and the output is returned through the same channel the operator or agent used to issue the original command, achieving disclosure without ever triggering a distinct 'unapproved command' flag.

Weaknesses (CWE)

CWE-200 — Exposure of Sensitive Information to an Unauthorized Actor: The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information.

  • [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.

CVSS Vector

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L

Timeline

Published
July 2, 2026
Last Modified
July 2, 2026
First Seen
July 2, 2026

Related Vulnerabilities