GHSA-xww8-gqvh-92x9: OpenClaw truncated approval UI

Q: Is GHSA-xww8-gqvh-92x9 actively exploited?

No confirmed active exploitation of GHSA-xww8-gqvh-92x9 has been reported, but organizations should still patch proactively.

Q: How to fix GHSA-xww8-gqvh-92x9?

Upgrade to openclaw@2026.5.18 or later, which fixes the approval display/binding mismatch — this is the only complete remediation. Until patched, restrict who can approve exec requests to a small set of trusted, security-aware operators, and instruct approvers to reject (not approve) any exec request whose command text appears unusually long or looks like it could be truncated in the UI. Where feasible, add server-side detection/alerting for exec-approval requests exceeding a reasonable command-length threshold, and audit recent approval logs for oversized commands approved before the patch was applied, correlating against actual process execution logs on hosts where OpenClaw exec ran to confirm the executed command matched what was displayed. Longer term, treat approval-UI fidelity (what's shown == what's bound) as a testable security control for any agent framework with human-in-the-loop exec gating.

Q: What systems are affected by GHSA-xww8-gqvh-92x9?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, human-in-the-loop approval workflows, autonomous coding/DevOps agents.

Q: What is the CVSS score for GHSA-xww8-gqvh-92x9?

GHSA-xww8-gqvh-92x9 has a CVSS v3.1 base score of 8.0 (HIGH).

CISO Take

OpenClaw's exec approval workflow could display a shortened version of a pending command while silently binding the full, unshortened command for execution — so an approver reviewing a long request could see only a benign-looking prefix and unknowingly authorize a hidden malicious suffix to run afterward. This is a CVSS 8.0 (high) authorization-integrity flaw (CWE-284/CWE-863) that undermines the human-in-the-loop control organizations rely on to keep AI agents safe, and it affects any deployment where exec approval is enabled and an authenticated caller can submit an oversized command. There is no evidence of active exploitation (not in CISA KEV, no EPSS score published, no public PoC or Nuclei template), which lowers urgency but does not lower impact — a successful approver deception yields full command-and-scripting-interpreter execution with high confidentiality, integrity, and availability impact. Upgrade to openclaw 2026.5.18 or later immediately; until patched, restrict exec-approval capability to a small set of trusted operators and treat any unusually long pending command as a hard reject rather than an approve.

Sources: GitHub Advisory ATLAS CISA KEV

What is the risk?

High severity (CVSS 8.0, AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H) driven by an authorization-integrity failure rather than a classic auth bypass: exploitation still requires an authenticated caller able to submit exec-approval requests and a human approver to act on the deceptive UI, which narrows the practical attacker population but does not eliminate insider or compromised-account risk. No active exploitation signals exist (not in CISA KEV, no EPSS, no public exploit or scanner template), so this reads as a disclosed integrity gap rather than an in-the-wild threat today. However, the blast radius is amplified by what the flaw undermines: the very approval gate meant to be the last line of defense before an AI agent executes host-level shell commands. Any organization running OpenClaw with exec approval enabled — especially where approvers are not the same people who requested the action — should treat this as a near-term patch priority even absent telemetry of exploitation.

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

8.0 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC Low

PR Low

UI Required

S Unchanged

C High

I High

A High

What should I do?

1 step

Upgrade to openclaw@2026.5.18 or later, which fixes the approval display/binding mismatch — this is the only complete remediation. Until patched, restrict who can approve exec requests to a small set of trusted, security-aware operators, and instruct approvers to reject (not approve) any exec request whose command text appears unusually long or looks like it could be truncated in the UI. Where feasible, add server-side detection/alerting for exec-approval requests exceeding a reasonable command-length threshold, and audit recent approval logs for oversized commands approved before the patch was applied, correlating against actual process execution logs on hosts where OpenClaw exec ran to confirm the executed command matched what was displayed. Longer term, treat approval-UI fidelity (what's shown == what's bound) as a testable security control for any agent framework with human-in-the-loop exec gating.

How is it classified?

Auth Bypass Code Execution Social Engineering Agent Plugin AML.T0050 - Command and Scripting Interpreter AML.T0053 - AI Agent Tool Invocation AML.T0074 - Masquerading

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 14 - Human oversight

ISO 42001

A.6.2.4 - Human oversight of AI system operation

NIST AI RMF

GOVERN 4.1 - Organizational risk management processes reflect appropriate mechanisms for human oversight

OWASP LLM Top 10

LLM08 - Excessive Agency

Frequently Asked Questions

What is GHSA-xww8-gqvh-92x9?

OpenClaw's exec approval workflow could display a shortened version of a pending command while silently binding the full, unshortened command for execution — so an approver reviewing a long request could see only a benign-looking prefix and unknowingly authorize a hidden malicious suffix to run afterward. This is a CVSS 8.0 (high) authorization-integrity flaw (CWE-284/CWE-863) that undermines the human-in-the-loop control organizations rely on to keep AI agents safe, and it affects any deployment where exec approval is enabled and an authenticated caller can submit an oversized command. There is no evidence of active exploitation (not in CISA KEV, no EPSS score published, no public PoC or Nuclei template), which lowers urgency but does not lower impact — a successful approver deception yields full command-and-scripting-interpreter execution with high confidentiality, integrity, and availability impact. Upgrade to openclaw 2026.5.18 or later immediately; until patched, restrict exec-approval capability to a small set of trusted operators and treat any unusually long pending command as a hard reject rather than an approve.

Is GHSA-xww8-gqvh-92x9 actively exploited?

No confirmed active exploitation of GHSA-xww8-gqvh-92x9 has been reported, but organizations should still patch proactively.

How to fix GHSA-xww8-gqvh-92x9?

Upgrade to openclaw@2026.5.18 or later, which fixes the approval display/binding mismatch — this is the only complete remediation. Until patched, restrict who can approve exec requests to a small set of trusted, security-aware operators, and instruct approvers to reject (not approve) any exec request whose command text appears unusually long or looks like it could be truncated in the UI. Where feasible, add server-side detection/alerting for exec-approval requests exceeding a reasonable command-length threshold, and audit recent approval logs for oversized commands approved before the patch was applied, correlating against actual process execution logs on hosts where OpenClaw exec ran to confirm the executed command matched what was displayed. Longer term, treat approval-UI fidelity (what's shown == what's bound) as a testable security control for any agent framework with human-in-the-loop exec gating.

What systems are affected by GHSA-xww8-gqvh-92x9?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, human-in-the-loop approval workflows, autonomous coding/DevOps agents.

What is the CVSS score for GHSA-xww8-gqvh-92x9?

GHSA-xww8-gqvh-92x9 has a CVSS v3.1 base score of 8.0 (HIGH).

What is the AI security impact?

Affected AI Architectures

agent frameworkshuman-in-the-loop approval workflowsautonomous coding/DevOps agents

MITRE ATLAS Techniques

AML.T0050 Command and Scripting Interpreter

AML.T0053 AI Agent Tool Invocation

AML.T0074 Masquerading

Compliance Controls Affected

EU AI Act: Article 14

ISO 42001: A.6.2.4

NIST AI RMF: GOVERN 4.1

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

### Summary OpenClaw exec approvals could show a shortened command in the approval UI while keeping the full original command for execution. For very long commands, an approver could see and approve a benign-looking prefix while a hidden suffix remained part of the command that would run after approval. This issue affects the approval display and binding for oversized exec commands. It does not make exec available to unauthenticated users, and it does not change OpenClaw's local-first trust model. ### Affected configurations This affects deployments where exec approval is enabled and an authenticated caller can create a pending host exec request with a command long enough to be truncated in the approval view. ### Impact An approver could make a decision from incomplete command text. If the hidden suffix contained additional shell operations, those operations could run after the approval was resolved. The practical impact depends on who can request exec approvals and who is allowed to approve them. The issue is an approval integrity problem: the approval surface did not faithfully represent the command that would execute. ### Patched Versions The first stable patched version is `2026.5.18`. ### Mitigations Upgrade to `openclaw@2026.5.18` or later. Before upgrading, avoid approving unusually long exec commands and keep approval capability limited to trusted operators.

Exploitation Scenario

An authenticated but lower-trust user (or a compromised account, or a malicious/manipulated upstream agent step) submits an exec-approval request built as a long, seemingly innocuous shell command — e.g., a routine file-listing or build command — with a hidden secondary operation (such as a reverse shell, credential exfiltration, or destructive command) appended past the point where OpenClaw's UI truncates the displayed text. A time-pressed approver, seeing only the benign prefix, approves the request believing it is safe. Because the binding used the full original command rather than the displayed one, execution proceeds to run both the benign prefix and the hidden suffix on the host, giving the attacker command execution with whatever privileges the OpenClaw exec agent holds — potentially enabling lateral movement, data exfiltration, or persistence, all logged as an 'approved' action that looks legitimate in audit trails.

Weaknesses (CWE)

CWE-284 Improper Access Control Primary CWE-863 Incorrect Authorization 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.