| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability where Allow Always approvals for exact commands persist as path-only grants on macOS and Linux. Attackers can reuse the same executable with different arguments to execute commands without triggering new approval prompts, potentially accessing files or internal services. |
| OpenClaw (npm package openclaw) versions >= 2026.5.2 and < 2026.8.1 contain an incorrect authorization vulnerability in WhatsApp group handling. A group sender who is admitted for ordinary messages but denied by commands.allowFrom or owner command authorization can issue the /new <model> command to reset the shared group session and persist a provider and model override. This allows a command-denied group member to select a provider and model already permitted by the operator for subsequent turns in the shared group session, potentially changing provider routing, cost, data flow, or availability. It does not allow adding a new provider or host command execution. The issue is fixed in version 2026.8.1. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 does not correctly enforce per-chat tool policies for Codex app-server runtime tools. A conversation-level tools.allow rule filtered OpenClaw tools but did not restrict the shell, process, file, and patch tools owned by the Codex runtime. When a lower-trust conversation was assigned to a Codex runtime and restricted with a per-chat tool allowlist, a participant able to trigger that agent could still reach native command and file tools, bypassing the configured allowlist. The practical impact depends on the runtime's host permissions and sandbox configuration. The issue is fixed in 2026.8.1. |
| OpenClaw (npm package 'openclaw') versions >= 2026.3.28 and < 2026.8.1 contain a credential exposure issue in memory embedding failover. When remote embedding fallback is configured and the primary embedding provider fails, the request can be sent to a different fallback provider while still reusing the primary provider's configured API key, causing that credential to be transmitted as a bearer token to an unintended vendor. The practical impact depends on the configured providers, whether failover occurs, and the privileges attached to the primary provider key. The issue is fixed in 2026.8.1; as a workaround, disable cross-provider embedding fallback or configure each provider with separate, narrowly scoped credentials. |
| openclaw's @openclaw/voice-call package before 2026.8.1 launches the configured agent for classic inbound voice calls without propagating the caller's identity or non-owner status. As a result, owner-only tool filtering can fail open and expose the agent's normal tool authority to a remote caller. A caller who is admitted by the configured inbound-call policy (open, pairing, or allowlist) on a deployment with inbound calling enabled can therefore drive tools intended for the trusted owner, potentially reading data, modifying files, executing commands, or controlling connected services depending on the agent's configuration. The issue is fixed in 2026.8.1. |
| OpenClaw Feishu before 2026.8.1 fails to validate whether a configured default account is disabled before selecting it for model tool operations. Attackers can exploit multi-account setups where a disabled default account retains credentials to read or modify Feishu resources through a revoked identity. |
| OpenClaw versions before 2026.8.1 fail to validate all source fields in structured message attachments, allowing attackers to hide unvalidated host paths behind allowed attachment sources. Attackers can exploit this by providing multiple source fields to bypass sandbox path validation and cause Telegram delivery to read and send known host files that would otherwise be rejected. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 could send third-party provider credentials to the wrong endpoint. In affected versions, when a third-party provider uses an OpenAI-compatible API and the resolved model metadata lacks a concrete base URL, a pinned session that continues after a model configuration hot reload retains that provider's credential while the OpenAI SDK selects its own default endpoint. A resulting request could disclose the configured third-party provider credential to an unrelated provider endpoint and fail with a misleading authentication error. Operators who observed this condition should rotate the affected credential. The issue is fixed in 2026.8.1. |
| OpenClaw before 2026.9.5 contains an incorrect authorization vulnerability in the Gateway's local media root allowlist that breaks filesystem isolation between sandboxed sessions. Sandboxed sessions or untrusted content can cause the Gateway to read files from sibling session sandboxes or shared workspace directories through media pipeline functions that fail to restrict reads to the active session. |
| OpenClaw before 2026.9.4 contains an incorrect authorization vulnerability in the mcp.app.view method that allows read-scoped operators to execute MCP App tools requiring operator.write scope. Attackers with operator.read tokens can obtain a standalone ticket from mcp.app.view and redeem it at the MCP app view endpoint to invoke state-changing tools without proper authorization checks. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 fails to apply the originating requester's effective tool policy during Active Memory automatic recall. In deployments that use Active Memory together with requester-specific tool rules, deterministic and hidden recall paths can retrieve durable memory and inject it into the agent's context even when toolsBySender explicitly denies that requester access to the memory tools (memory_search, memory_get). As a result, an admitted but denied sender can receive information derived from durable memory in the agent's response without directly invoking any memory tool. The issue is fixed in 2026.8.1. |
| OpenClaw versions before 2026.8.1 contain a path traversal vulnerability in the tools.fs.workspaceOnly feature where Unicode filename fallback can normalize validated parent directory components. Admitted requesters can exploit canonically equivalent sibling directories to read files outside the configured workspace boundary. |
| OpenClaw versions before 2026.8.1 contain an authorization scope widening vulnerability in file-transfer allow-always approvals that allows attackers to reuse standing grants for unreviewed paths. Attackers can exploit glob metacharacter interpretation and node display name reuse to access sibling paths or different nodes beyond the operator's original approval scope. |
| OpenClaw (npm package 'openclaw') before 2026.8.1 contains a server-side request forgery vulnerability in its trusted-host DNS checks. For fetches that use the trusted-host DNS recheck, a trusted hostname that resolves to an unspecified address (0.0.0.0 or ::) bypasses the SSRF destination validation. An attacker who can influence DNS for an allowed hostname can therefore cause a guarded fetch to reach a service bound only to loopback and disclose its response; the practical impact depends on the reachable service and the data it returns. Fixed in 2026.8.1. |
| OpenClaw (npm package 'openclaw') versions >= 2026.3.28 and < 2026.8.1 allow an untrusted workspace .env file to set the CLOUDSDK_PYTHON_ARGS environment variable. When an operator starts OpenClaw in attacker-controlled workspace content and then runs the Gmail setup flow, that value is inherited when gcloud is launched, and the gcloud launcher passes it as arguments to the trusted Python interpreter. A crafted CLOUDSDK_PYTHON_ARGS value can therefore cause Python to execute attacker-supplied code with the OpenClaw host user's permissions, allowing credentials to be read, files to be modified, or other processes to be started. This issue is fixed in version 2026.8.1; as a workaround, run Gmail setup only from trusted workspaces and clear inherited CLOUDSDK_* variables beforehand. |
| OpenClaw (npm package 'openclaw') versions >= 2026.3.22 and < 2026.8.1 contain an approval-bypass flaw in the exec approval policy: the policy could trust a command-running wrapper without inspecting the command carried in its arguments. After an operator allowlisted or permanently approved a benign wrapper invocation, a later agent turn could substitute an arbitrary inner command and execute it with the OpenClaw process's host privileges without a further approval prompt. Exploitation requires the relevant wrapper to resolve on the host and a prior operator decision allowing that wrapper. Transparent shell carriers and opaque utilities such as process monitors, tracers, namespace tools, and proxy wrappers were affected through related trust-resolution gaps. Fixed in 2026.8.1. |
| OpenClaw versions before 2026.8.1 contain an authorization bypass vulnerability in skill tool dispatch that fails to carry the sender's owner status. Non-owner senders authorized to invoke skill commands can access owner-only tools and server credentials reserved for owners. |
| OpenClaw versions >= 2026.6.9 and < 2026.8.1 do not declare the native chatId parameter as a delivery target in the Feishu unpin feature, so unpin requests can bypass the shared same-provider cross-context target check. When tools.message.crossContext.allowWithinProvider is disabled, an admitted (authenticated) sender can remove a pin from another Feishu group that the sender and the configured account are otherwise permitted to access, bypassing the intended cross-context message mutation policy. Feishu membership and group authorization still apply, and the demonstrated impact is limited to message mutation (pin removal). The issue is fixed in 2026.8.1. |
| OpenClaw versions before 2026.8.1 contain a path traversal vulnerability in QQBot voice attachment handling where filenames are decoded twice, allowing encoded traversal segments to reappear after sanitization. Attackers can supply crafted voice attachments that write files outside the intended staging directory to other process-writable locations. |
| OpenClaw (npm package `openclaw`) before 2026.8.1 incorrectly enforces sender tool policies during session-memory filename generation. In affected versions, filename generation created an embedded helper that retained tools which the originating sender's policy had removed. When session-memory filename generation was enabled for an agent reachable by lower-trust senders, model-mediated instructions could cause the helper to invoke tools outside that sender's effective policy; the demonstrated impact was the creation of persistent scheduled work. Exploitability depends on the model acting on the injected instruction and on which tools the helper exposes. The issue is fixed in 2026.8.1; as a workaround, disable session-memory filename generation for agents reachable by lower-trust senders. |
