AI Threat Alert
GHSA-2j8v-hwgc-x698: OpenClaw: TOCTOU in shell wrapper bypasses command allowlist
GHSA-2j8v-hwgc-x698 HIGHOpenClaw's shell-wrapper feature can let a command's approved argv diverge from what actually executes, letting an unchecked command shape run outside the configured allowlist. This is a classic time-of-check/time-of-use gap in an AI agent's authorization layer, not a novel jailbreak, but it directly undermines the control CISOs rely on to constrain what an autonomous agent can execute on a Gateway host. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS data isn't available, so this looks pre-exploitation rather than actively weaponized — but the fix (2026.5.18) is already public, which shortens the window before reverse-engineered patches turn into working PoCs. Only 4 downstream dependents are tracked, limiting blast radius today, but any Gateway shared across mutually untrusted users or exposed to lower-trust input (plugins, external requests) should be treated as exposed. Patch to 2026.5.18 immediately; until then, require explicit human approval for every shell-wrapper invocation and avoid durable/pre-approved allowlists for wrapper-heavy commands.
What is the risk?
Rated high severity via CWE-284 (Improper Access Control). Exploitability is moderate: an attacker needs the ability to submit a command request through the affected shell-wrapper feature and enough understanding of the approval/execution split to craft an argv that resolves differently at each stage. No public exploit code, scanner template, or KEV listing exists, and EPSS data is unavailable, so real-world exploitation activity cannot be confirmed at this time — this keeps near-term likelihood LOW-MEDIUM. However, impact is significant where realized: it defeats the primary control (the allowlist) meant to constrain what commands an AI agent's Gateway can run, effectively converting a scoped automation surface into an arbitrary-command surface for whoever can reach it. Risk scales with configuration — Gateways shared across mutually untrusted users, or with the shell-wrapper feature enabled and reachable by lower-trust input, carry materially higher exposure than single-operator, tightly scoped deployments.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| OpenClaw | npm | <= 2026.5.16 | 2026.5.18 |
Do you use OpenClaw? You're affected.
How severe is it?
What should I do?
1 step-
1) Patch to OpenClaw 2026.5.18 or later — this is the primary fix. 2) Until patched, require explicit human approval for every shell-wrapper command request rather than relying on pre-approved/durable allowlists for wrapper-heavy commands. 3) Keep channel and tool allowlists as narrow as possible regardless of patch status. 4) Never share a single Gateway between mutually untrusted users or trust domains. 5) Disable the shell-wrapper feature entirely if it isn't operationally required. 6) For detection, audit Gateway command execution logs for discrepancies between the argv shown at approval time and the argv actually executed, and flag any executed command that wouldn't independently pass the configured allowlist. 7) Review recent command history on affected Gateways for evidence of shape mismatches predating the patch.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is GHSA-2j8v-hwgc-x698?
OpenClaw's shell-wrapper feature can let a command's approved argv diverge from what actually executes, letting an unchecked command shape run outside the configured allowlist. This is a classic time-of-check/time-of-use gap in an AI agent's authorization layer, not a novel jailbreak, but it directly undermines the control CISOs rely on to constrain what an autonomous agent can execute on a Gateway host. There's no CISA KEV listing, no public exploit or Nuclei template, and EPSS data isn't available, so this looks pre-exploitation rather than actively weaponized — but the fix (2026.5.18) is already public, which shortens the window before reverse-engineered patches turn into working PoCs. Only 4 downstream dependents are tracked, limiting blast radius today, but any Gateway shared across mutually untrusted users or exposed to lower-trust input (plugins, external requests) should be treated as exposed. Patch to 2026.5.18 immediately; until then, require explicit human approval for every shell-wrapper invocation and avoid durable/pre-approved allowlists for wrapper-heavy commands.
Is GHSA-2j8v-hwgc-x698 actively exploited?
No confirmed active exploitation of GHSA-2j8v-hwgc-x698 has been reported, but organizations should still patch proactively.
How to fix GHSA-2j8v-hwgc-x698?
1) Patch to OpenClaw 2026.5.18 or later — this is the primary fix. 2) Until patched, require explicit human approval for every shell-wrapper command request rather than relying on pre-approved/durable allowlists for wrapper-heavy commands. 3) Keep channel and tool allowlists as narrow as possible regardless of patch status. 4) Never share a single Gateway between mutually untrusted users or trust domains. 5) Disable the shell-wrapper feature entirely if it isn't operationally required. 6) For detection, audit Gateway command execution logs for discrepancies between the argv shown at approval time and the argv actually executed, and flag any executed command that wouldn't independently pass the configured allowlist. 7) Review recent command history on affected Gateways for evidence of shape mismatches predating the patch.
What systems are affected by GHSA-2j8v-hwgc-x698?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, AI agent tool invocation, Gateway/orchestration layer.
What is the CVSS score for GHSA-2j8v-hwgc-x698?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0050 Command and Scripting Interpreter AML.T0053 AI Agent Tool Invocation AML.T0102 Generate Malicious Commands AML.T0112.000 Local AI Agent Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Shell wrapper argv could change between approval and execution. In affected versions, a command request using a shell wrapper form could approve one resolved argv shape and rebuild another for execution. 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 run a command shape that was not checked against the allowlist. 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.18`. ### Mitigations require explicit approval for shell wrappers and avoid durable allowlists for wrapper-heavy commands 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 attacker with the ability to submit a command request to an OpenClaw Gateway — e.g., a lower-privilege user on a shared Gateway, or input arriving via an installed plugin — crafts a shell-wrapper command whose resolved argv looks benign and allowlist-compliant at approval time (say, a harmless read-only utility invocation). Because of the TOCTOU flaw, the execution path independently rebuilds the argv from the same wrapper input, producing a different command shape than what was checked — for example substituting or appending arguments that were never evaluated against the allowlist. The Gateway executes this rebuilt command with whatever privileges the agent process holds, giving the attacker command execution outside the intended policy boundary. On a Gateway shared across users or connected to broader infrastructure, this could be chained into credential harvesting, lateral movement, or data exposure well beyond the narrowly-scoped action the operator believed they were approving.
Weaknesses (CWE)
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.
References
Timeline
Related Vulnerabilities
CVE-2026-33579 9.9 OpenClaw: scope bypass escalates low-priv to admin
Same package: openclaw CVE-2026-32922 9.9 OpenClaw: privilege escalation to RCE via token scope bypass
Same package: openclaw CVE-2026-30741 9.8 OpenClaw: RCE via request-side prompt injection
Same package: openclaw CVE-2026-32038 9.8 OpenClaw: sandbox bypass enables container lateral movement
Same package: openclaw CVE-2026-53838 9.8 OpenClaw: approval scope bypass via reconnection state
Same package: openclaw