Summary
OpenClaw's exec allowlist supported optional argPattern entries to restrict the arguments accepted for an allowlisted executable. In affected releases, Linux and macOS gateways skipped argPattern checks and treated a matching executable path as sufficient to satisfy the allowlist.
This meant an operator could configure an allowlist entry that appeared to permit only a narrow argv shape, but OpenClaw would allow other argv for the same executable without an approval prompt when tools.exec.security was set to allowlist.
This issue is limited to direct enforcement of configured argPattern values. OpenClaw's exec approvals remain best-effort guardrails and do not attempt to semantically model every interpreter, loader, package script, shell feature, or transitive file a command may use.
Affected configurations
This affects OpenClaw gateway deployments that meet all of these conditions:
- the gateway runs on Linux or macOS - exec is configured with tools.exec.security: "allowlist" - at least one exec allowlist entry uses argPattern - the allowlisted executable accepts security-relevant arguments or flags
Path-only allowlist entries are not additionally affected by this issue, because those entries intentionally allow any arguments for the matched executable. Windows was not affected by this specific bug because the affected code path already applied argPattern checks on Windows.
Impact
If an untrusted or lower-trust sender can influence a tool-enabled agent to call exec, they may be able to run disallowed arguments for an executable that the operator intended to restrict with argPattern. Depending on the executable, those arguments can cause host-side file access, network access, or command execution that should have required an approval prompt.
The practical impact depends on the operator's allowlist and channel exposure. Examples of higher-risk allowlisted executables include tools with interpreter, loader, subprocess, network, or plugin flags such as git, python, node, bash, find, tar, and ssh.
This is not a bypass of all exec approval semantics. It is a bypass of the direct argPattern predicate that the operator configured and that the exec tool description advertised as enforced at runtime.
Patched Versions
The first stable patched version is 2026.5.12.
Mitigations
Upgrade to openclaw@2026.5.12 or later. Before upgrading, operators who use exec allowlist mode should review entries that combine an executable path with argPattern, especially for interpreter-like or subprocess-capable tools.
Summary
Exported session HTML could keep unsafe markdown links. In affected versions, content rendered into an exported session could preserve unsafe javascript: or data: links in generated HTML.
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 browser-side script if a trusted operator opens the exported file and activates the link. 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
do not open exported session HTML from untrusted content in a privileged browser profile 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.
Summary
Slack reaction events could ignore reaction notification settings. In affected versions, a Slack reaction event delivered to the configured app could enter the agent pipeline even when reaction notifications were disabled.
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 trigger unintended agent processing for reaction events. 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
disable or restrict Slack reaction event subscriptions until patched if this path is not needed. 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.
Summary
Bootstrap token replay could widen pending pairing scopes. In affected versions, a caller with access to a pending bootstrap token could reuse the token before approval with a broader requested scope set.
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 present or retain broader pending pairing authority than intended. 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
treat pairing codes as sensitive and cancel unexpected pending pairings 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.
Summary
Shell inline-command parsing could miss an allowlist check. In affected versions, a command request using shell inline-command forms could route an inline command through a parser case that did not receive the expected allowlist decision.
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 shell content without the intended approval or allowlist prompt. 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
require approval for shell inline-command forms 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.
Summary
OpenClaw supports remote MCP Streamable HTTP servers with operator-configured custom headers. In affected releases, those headers could be forwarded when the MCP endpoint responded with a cross-origin redirect.
This issue is limited to configured MCP Streamable HTTP servers that use custom headers. It does not expose unrelated OpenClaw credentials.
Affected configurations
This affects deployments where an MCP server is configured with:
- transportType: "streamable-http" - sensitive custom headers under mcp.servers..headers - an MCP endpoint that is malicious, compromised, or able to redirect to another origin
Impact
Custom MCP headers, such as API keys or tenant-routing headers, could be sent to the redirect target. The exposed credential scope depends on the header the operator configured for that MCP server.
Patched Versions
The first stable patched version is 2026.5.12.
Mitigations
Upgrade to openclaw@2026.5.8 or later. Before upgrading, avoid custom MCP headers with servers you do not fully trust, and rotate any MCP-specific credentials that may have been exposed by a redirecting endpoint.