GHSA-xww8-gqvh-92x9: OpenClaw: Exec approval display truncation could hide the command being approved

Exec approval is meant to let a human see a command before it runs on the host. For very long commands, the approval view truncated the text, but the pending request still held the full original command. What the approver saw and what would run were not the same string. This is an approval integrity problem, not a bypass of the approval step itself.

The attacker is an authenticated caller, or an agent flow, that can create a pending host exec request. They pad a command so that a benign prefix fills the visible part and shell operations sit in the hidden suffix. A human then has to approve it, which is why the vector marks user interaction as required. After approval, the whole command runs with the host privileges of the OpenClaw process.

The advisory does not give the truncation length. Exposure depends on who can request approvals and who approves them. It matters most where agents propose commands and a person clicks approve. It does not make exec available to unauthenticated users.

The npm package openclaw before 2026.5.18, 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.

npm ls openclaw

Use npm ls -g openclaw for a global install. Anything below 2026.5.18 is affected.

Upgrade to [email protected] or later, the first stable patched version:

npm install [email protected]

Before upgrading, the advisory says to avoid approving unusually long exec commands and to keep approval capability limited to trusted operators. The advisory does not describe how the fix changes the display.

Review the history of approved exec requests for unusually long commands, and compare the full stored command with what shows in your approval records. Look for commands with a harmless start followed by ;, &&, a pipe or a download-and-run step far down the string. The advisory gives no log line. Beam records agent shell commands as they run, and its rules flag risky ones, so the command that actually executed can be checked against what was approved.

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 [email protected] or later. Before upgrading, avoid approving unusually long exec commands and keep approval capability limited to trusted operators.