Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
571 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
In affected versions of openclaw, a gateway caller with operator.write could issue agent requests containing /new or /reset and reach the same reset path used by the admin-only sessions.reset RPC. Impact On gateways where a caller is intentionally granted operator.write but not operator.admin, that caller could reset targeted conversation state through agent slash commands. This crosses the documented method-scope boundary between write-scoped messaging and admin-only session mutation. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details Scope checks were enforced only on the outer RPC method. The agent slash-command path reused admin-only reset logic internally, so a write-scoped caller could reach session-reset mutation without holding operator.admin. Fix OpenClaw no longer routes conversation /new and /reset through the admin-only sessions.reset entry point. Reset logic now lives in a shared…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, node-host system.run approvals did not bind a mutable file operand for some script runners, including forms such as tsx and jiti. An attacker could obtain approval for a benign script-runner command, rewrite the referenced script on disk, and have the modified code execute under the already approved run context. Impact Deployments that rely on node-host system.run approvals for script integrity could execute rewritten local code after operator approval. This can lead to unintended local code execution as the OpenClaw runtime user. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: < 2026.3.11 - Fixed in: 2026.3.11 Technical Details The approval planner only tracked mutable script operands for a hardcoded set of interpreters and runtime forms. Commands such as tsx ./run.ts and jiti ./run.ts fell through without a bound file snapshot, so the final pre-execution revalidation step was skipped. Fix OpenClaw now fails…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, channel-initiated config mutations were authorized against the originating account's configWrites policy but did not consistently re-check the targeted account scope. An authorized sender on one account could mutate protected sibling-account configuration when the target account had configWrites: false. Impact This is an account-scoped policy bypass inside a single gateway deployment. Channel commands such as /config set channels.<provider.accounts.<id... and config-backed /allowlist ... --config --account <id could modify protected sibling-account configuration. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details The mutation path validated the origin account scope but did not consistently authorize every resolved target scope. Ambiguous collection and root writes under channels and channels.<provider.accounts could therefore reach protected account configuration…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, node-host system.run approvals could display only an extracted shell payload such as jq --version while execution still ran a different outer wrapper argv such as ./env sh -c 'jq --version'. Impact This is an approval-integrity bug. An attacker who could place or select a local wrapper binary and induce a wrapper-shaped command could get local code executed after the operator approved misleading command text. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details Wrapper resolution normalized executables by basename and extracted inner shell payload text for approval display, while execution still preserved the full wrapper argv. Approval storage and UI therefore showed text that did not match the exact command OpenClaw would execute. Fix OpenClaw now binds approvals to the exact executed argv and keeps extracted shell payload text only as secondary preview data. The…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, node-host system.run approvals could still execute rewritten local code for interpreter and runtime commands when OpenClaw could not bind exactly one concrete local file operand during approval planning. Impact Deployments using node-host system.run approval mode could approve a benign local script and then execute different local code if that script changed before execution. This can lead to unintended local code execution as the OpenClaw runtime user. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details The approval flow treated some interpreter and runtime forms as approval-backed even when it could not honestly bind a single direct local script file. That left residual approval-integrity gaps for runtime forms outside the directly bound file set. Fix OpenClaw now fails closed for approval-backed interpreter and runtime commands unless it can bind exactly one…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, sandboxed leaf subagents could still access the subagents control surface and resolve against the parent requester scope instead of remaining confined to their own session tree. Impact A low-privilege sandboxed leaf worker could steer or kill a sibling run owned by the same requester and cause that sibling to execute with its own broader tool policy. This is a sandbox and session-scope boundary bypass. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details Leaf subagents retained the subagents tool, and subagent control requests were authorized against the parent requester scope rather than the caller's own spawned descendants. The control path prevented only self-targeting, not cross-sibling steering. Fix OpenClaw now removes subagents control access from leaf subagents by default, scopes subagent control to the caller's own descendants, and rejects steer and kill…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, a caller holding only operator.pairing could use device.token.rotate to mint a new token with broader scopes for an already paired device. If the target device was approved for operator.admin, the attacker could obtain an administrative token without already holding administrative scope. Impact This is a critical authorization flaw. On deployments with connected node hosts or companion apps that expose system.run, the escalated token could then modify node execution approvals and reach real remote code execution on the node. Even without nodes, the flaw still granted unauthorized gateway-admin access. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details device.token.rotate accepted caller-supplied target scopes and validated them against the target device's approved scopes, but it did not constrain the newly minted scopes to the caller's own current scope set. That…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, the plugin subagent runtime dispatched gateway methods through a synthetic operator client that always carried broad administrative scopes. Plugin-owned HTTP routes using auth: "plugin" could therefore trigger admin-only gateway actions without normal gateway authorization. Impact This is a critical authorization bypass. An external unauthenticated request to a plugin-owned route could reach privileged subagent runtime methods and perform admin-only gateway actions such as deleting sessions, reading session data, or triggering agent execution. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: = 2026.3.7, < 2026.3.11 - Fixed in: 2026.3.11 Technical Details The new plugin subagent runtime preserved neither the original caller's auth context nor least-privilege scope. Instead, it executed gateway dispatches through a fabricated operator client with administrative scopes, which was reachable from plugin-owned routes…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, the sandbox fs-bridge writeFile commit step used an unanchored container path during the final move into place. An attacker racing parent-path changes inside the sandbox could redirect the committed file outside the validated sandbox path. Impact This is a sandbox boundary bypass. In-sandbox code could win a time-of-check-time-of-use race and cause host-approved writeFile operations to land outside the validated writable path within the container mount namespace. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: < 2026.3.11 - Fixed in: 2026.3.11 Technical Details The hardening work for anchored remove, rename, and mkdir operations did not fully cover the writeFile commit path. The final mv still used the raw target path, leaving a race window between safety revalidation and the in-container commit step. Fix OpenClaw now anchors the writeFile commit path to the canonical parent directory before the final move. The…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of openclaw, browser-originated WebSocket connections could bypass origin validation when gateway.auth.mode was set to trusted-proxy and the request arrived with proxy headers. A page served from an untrusted origin could connect through a trusted reverse proxy, inherit proxy-authenticated identity, and establish a privileged operator session. Impact This issue affects deployments that expose the Gateway behind a trusted reverse proxy and rely on browser origin checks such as controlUi.allowedOrigins to restrict browser access. An attacker who can cause a victim browser to load a malicious page that can reach the proxy endpoint could establish a cross-site WebSocket connection and call privileged Gateway methods. In verified impact, the attacker-origin page was able to request operator.admin and successfully call config.get, exposing sensitive configuration. Depending on the deployment, the same authenticated operator path could also permit other…
Recommended action: Upgrade to 2026.3.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Gateway auth for plugin channel endpoints can be bypassed when path canonicalization differs between the gateway guard and plugin handler routing. Details On affected versions, server-http only applies gateway auth when raw requestPath matches exactly: - /api/channels - /api/channels/ If a plugin handler canonicalizes path input (for example decodeURIComponent(pathname).toLowerCase()), requests like: - /API/channels/nostr/default/profile - /api/channels%2Fnostr%2Fdefault%2Fprofile can be interpreted as /api/channels/ by the plugin, while the gateway auth guard is skipped. Impact Authentication boundary bypass for plugin channel HTTP routes under canonicalization mismatch conditions. Unauthorized callers may access plugin channel APIs that are expected to require gateway auth. CWE: CWE-288 (Authentication Bypass Using an Alternate Path or Channel) CVSS: CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N (Base 5.3, Moderate)
Recommended action: Upgrade to 2026.2.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Slack member and message subtype system events (messagechanged, messagedeleted, threadbroadcast) were not consistently enforcing sender authorization before enqueueing system events. Affected Packages / Versions - Package: openclaw (npm) - Latest published version: 2026.2.25 - Affected range: <= 2026.2.25 - Planned patched version: 2026.2.26 (pre-set for publish-readiness) Technical Details Slack system-event handlers in src/slack/monitor/events/members.ts and src/slack/monitor/events/messages.ts enqueued events after channel checks without shared sender authorization. Deployments relying on Slack DM allowlists (dmPolicy / allowFrom) or per-channel users allowlists could receive unauthorized system-event ingress from non-allowlisted senders. The fix routes those handlers through authorizeAndResolveSlackSystemEventContext(...) and fails closed when message subtype sender identity cannot be resolved. Fix Commit(s) - 3d30ba18a2aba1e1b302e77ff33145c3b06c01c8 Release Process Note…
Recommended action: Upgrade to 2026.2.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A sandbox boundary-validation gap in symlink alias handling allowed certain workspace-only write paths to be treated as in-boundary even when they could resolve outside the workspace/sandbox root. Affected Packages / Versions - Package: npm openclaw - Affected versions: <= 2026.2.25 - Latest published npm version included in affected range: 2026.2.25 (checked on February 26, 2026) - Patched version (pre-set for release): 2026.2.26 Technical Details In affected versions, dangling symlink hops could be accepted during boundary checks under missing-target conditions. For workspace-only write flows (including applypatch), this could allow writes to resolve outside the configured workspace/sandbox boundary. The fix resolves symlink targets through existing ancestors and fails closed when canonical resolution escapes the configured boundary. Impact - Boundary-confined write operations could be redirected outside the configured workspace/sandbox root. - Primary impact is integrity…
Recommended action: Upgrade to 2026.2.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw had a workspace boundary bypass in workspace-only path validation: when an in-workspace symlink pointed outside the workspace to a non-existent leaf, the first write could pass validation and create the file outside the workspace. Affected Packages / Versions - Package: openclaw (npm) - Vulnerable versions: <= 2026.2.25 - Patched versions: = 2026.2.26 (pre-set for next planned release) - Latest published npm version at update time: 2026.2.25 Details The boundary check path resolved aliases in a way that allowed a non-existent out-of-root symlink target to pass the initial validation window. A first write through the guarded workspace path could therefore escape the workspace boundary. The fix hardens canonical boundary resolution so missing-leaf alias paths are evaluated against canonical containment, while preserving valid in-root aliases. This closes the first-write escape condition without regressing valid in-root alias usage. Fix Commit(s) -…
Recommended action: Upgrade to 2026.2.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In specific LINE configurations, sender IDs approved through DM pairing could also satisfy group allowlist checks when operators expected group sender access to be scoped only to explicit group allowlists. Affected Packages / Versions - Package: openclaw (npm) - Latest published version at triage/update time: 2026.2.25 - Affected: <= 2026.2.25 - Patched: = 2026.2.26 (planned next release) Impact This is a group-authorization scope mismatch. DM pairing-store entries could influence group sender authorization in allowlist mode. Technical Details Root cause: group allowlist composition inherited pairing-store entries intended for DM approvals. Under default DM pairing policy, a DM-paired sender could match group allowlist checks. Fixes on main: - isolate group allowlist composition from pairing-store entries - centralize shared DM/group allowlist composition to preserve DM-only pairing behavior - add regression coverage for LINE and Mattermost policy paths Fix Commit(s) -…
Recommended action: Upgrade to 2026.2.26 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's Microsoft Teams plugin widened group sender authorization when a team/channel route allowlist was configured but groupAllowFrom was empty. Before the fix, a matching route allowlist entry could cause the message handler to synthesize wildcard sender authorization for that route, allowing any sender in the matched team/channel to bypass the intended groupPolicy: "allowlist" sender check. This does not affect default unauthenticated access, but it does weaken a documented Teams group authorization boundary and can allow unauthorized group senders to trigger replies in allowlisted Teams routes. Affected Packages / Versions - Package: openclaw (npm) - Latest published vulnerable version: 2026.3.7 - Affected range: <= 2026.3.7 - Fixed in released version: 2026.3.8 Fix Commit(s) - 88aee9161e0e6d32e810a25711e32a808a1777b2 Release Verification - Verified fixed in GitHub release v2026.3.8 published on March 9, 2026. - Verified npm view openclaw version resolves to 2026.3.8. -…
Recommended action: Upgrade to 2026.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's skills download installer validated the intended per-skill tools root lexically, but later reused that mutable path while downloading and copying the archive into place. If a local attacker could rebind that tools-root path between validation and the final write, the installer could be redirected to write outside the intended tools directory. The fix pins the canonical per-skill tools root immediately after validation and derives later download/copy paths from that canonical root, so rebinding the lexical path fails closed instead of redirecting the write. Affected Packages / Versions - Package: openclaw (npm) - Latest published vulnerable version: 2026.3.7 - Affected range: <= 2026.3.7 - Fixed in released version: 2026.3.8 Fix Commit(s) - 9abf014f3502009faf9c73df5ca2cff719e54639 Release Verification - Verified fixed in GitHub release v2026.3.8 published on March 9, 2026. - Verified npm view openclaw version resolves to 2026.3.8. - Verified the release contains the…
Recommended action: Upgrade to 2026.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's system.run approval flow did not bind mutable interpreter-style script operands across approval and execution. A caller could obtain approval for an execution such as sh ./script.sh, rewrite the approved script before execution, and then execute different content under the previously approved command shape. The approved argv values remained the same, but the mutable script operand content could drift after approval. Latest published npm version verified vulnerable: 2026.3.7 The initial March 7, 2026 fix in c76d29208bf6a7f058d2cf582519d28069e42240 added approval binding for shell scripts and a narrow interpreter set, but follow-up maintainer review on March 8, 2026 found that bun and deno script operands still did not produce mutableFileOperand snapshots. A complete fix shipped on March 9, 2026 in cf3a479bd1204f62eef7dd82b4aa328749ae6c91, which binds approved bun and deno run script operands to on-disk file snapshots and denies post-approval script drift before execution.…
Recommended action: Upgrade to 2026.3.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Sandboxed requester sessions could reach host-side ACP session initialization through /acp spawn. OpenClaw already blocked sessionsspawn({ runtime: "acp" }) from sandboxed sessions, but the slash-command path initialized ACP directly without applying the same host-runtime guard first. Affected Packages / Versions - npm package: openclaw - Affected versions: <= 2026.3.2 - Patched version: = 2026.3.7 Details ACP sessions run on the host, not inside the OpenClaw sandbox. The direct ACP spawn path in src/agents/acp-spawn.ts already denied sandboxed requesters, but /acp spawn in src/auto-reply/reply/commands-acp/lifecycle.ts called initializeSession(...) without first applying the same restriction. In affected versions, an already authorized sender in a sandboxed session could use /acp spawn to cross from sandboxed chat context into host-side ACP runtime initialization when ACP was enabled and a backend was available. Fix Commit(s) - 61000b8e4ded919ca1a825d4700db4cb3fdc56e3 Fix…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's system.run allowlist analysis did not honor POSIX shell comment semantics when deriving allow-always persistence entries. A caller in security=allowlist mode who received an allow-always decision could submit a shell command whose tail was commented out at runtime, for example by using an unquoted before a chained payload. The runtime shell would execute only the pre-comment portion, but allowlist persistence could still analyze and store the non-executed tail as a trusted follow-up command. Latest published npm version: 2026.3.2 Fixed on main on March 7, 2026 in 939b18475d734ed75173f59507e3ebbdfe1992b7 by teaching shell tokenization and chain/pipeline analysis to stop at unquoted shell comments, so allow-always persistence now tracks only commands that the shell can actually execute. Normal real chained commands and quoted literals continue to work. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.2 - Patched version: = 2026.3.7…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A gateway client authenticated with operator.write could route /config set or /config unset through chat.send and reach persistent config mutation even though direct config RPC methods are admin-scoped. Affected Packages / Versions - Package: openclaw (npm) - Latest published vulnerable version: 2026.3.2 - Affected range: <= 2026.3.2 - Patched in: 2026.3.7 Details Before the fix, chat.send ran slash commands in an internal gateway-chat context with CommandAuthorized: true, and /config write paths only checked command authorization plus commands.config / channels.<provider.configWrites gates. That allowed an authenticated operator.write gateway client to bridge into persistent config writes even though direct config. RPC methods remain operator.admin scoped. The fix keeps command functionality intact while restoring the intended scope boundary: - persistent /config set|unset writes routed through gateway chat.send now require operator.admin - read-only /config show remains…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's system.run dispatch-wrapper handling applied different depth-boundary rules to shell-wrapper approval detection and execution planning. With exactly four transparent dispatch wrappers such as repeated env invocations before /bin/sh -c, the approval classifier could stop treating the command as a shell wrapper at the depth boundary while execution planning still unwrapped through to the shell payload. In security=allowlist mode, that mismatch could skip the expected approval-required path for the shell wrapper invocation. Latest published npm version: 2026.3.2 Fixed on main on March 7, 2026 in 2fc95a7cfc1eb9306356510b0251b6d51fb1c0b0 by keeping shell-wrapper classification active at the configured dispatch depth boundary and only failing closed beyond that boundary. This aligns approval gating with the execution plan. Legitimate shallow dispatch-wrapper usage continues to work. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.2 - Patched…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's fetchWithSsrFGuard(...) followed cross-origin redirects while preserving arbitrary caller-supplied headers except for a narrow denylist (Authorization, Proxy-Authorization, Cookie, Cookie2). This allowed custom authorization headers such as X-Api-Key, Private-Token, and similar sensitive headers to be forwarded to a different origin after a redirect. The fix switches cross-origin redirect handling from a narrow sensitive-header denylist to a safe-header allowlist, so only benign headers such as content negotiation and cache validators survive an origin change. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.2 - Patched version: 2026.3.7 - Latest published npm version at patch time: 2026.3.2 Impact A remote service that could trigger a redirect across origins could receive custom authorization credentials attached by OpenClaw callers. This can expose API keys, bearer-style custom headers, or private token headers intended only for the…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
/allowlist ... --store resolved the selected channel accountId for reads, but store writes still dropped that accountId and wrote into the legacy unscoped pairing allowlist store. Because default-account reads still merge legacy unscoped entries, a store entry intended for one account could silently authorize the same sender on the default account. This is a real cross-account sender-authorization scoping bug. Severity is set to medium because exploitation requires an already-authorized user who can run /allowlist edits. Affected Packages / Versions - Package: openclaw (npm) - Latest published version checked: 2026.3.2 - Affected versions: <= 2026.3.2 - Fixed on main: March 7, 2026 in 70da80bcb5574a10925469048d2ebb2abf882e73 - Patched release: 2026.3.7 Details The affected path was: - src/auto-reply/reply/commands-allowlist.ts:386-393 resolved accountId and read store state with it - src/auto-reply/reply/commands-allowlist.ts:697-702 and…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's system.run shell-wrapper detection did not recognize PowerShell -EncodedCommand forms as inline-command wrappers. In allowlist mode, a caller with access to system.run could invoke pwsh or powershell using -EncodedCommand, -enc, or -e, and the request would fall back to plain argv analysis instead of the normal shell-wrapper approval path. This could allow a PowerShell inline payload to execute without the approval step that equivalent -Command invocations would require. Latest published npm version: 2026.3.2 Fixed on main on March 7, 2026 in 1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d by recognizing PowerShell encoded-command aliases during shell-wrapper parsing, so allowlist mode continues to require approval for those payloads. Normal approved PowerShell wrapper flows continue to work. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.2 - Patched version: = 2026.3.7 Fix Commit(s) - 1d1757b16f48f1a93cd16ab0ad7e2c3c63ce727d Release Process…
Recommended action: Upgrade to 2026.3.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.