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.
Nostr inbound DM handling could perform crypto and dispatch work before sender and pairing policy enforcement, enabling unauthorized pre-auth computation. Affected Packages / Versions - Package: openclaw (npm) - Affected: < 2026.3.22 - Fixed: = 2026.3.22 - Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked: 2026.3.23-2 Fix Commit(s) - 1ee9611079e81b9122f4bed01abb3d9f56206c77 Release Status The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2. Code-Level Confirmation - extensions/nostr/src/channel.ts now performs authorization before decrypting and dispatching inbound DM content. - extensions/nostr/src/nostr-bus.ts adds pre-crypto authorization, size, and rate guardrails before expensive decrypt work. OpenClaw thanks @kuranikaran for reporting.
Recommended action: Upgrade to 2026.3.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Synology Chat reply delivery could rebind to a mutable username match instead of the stable numeric userid recorded by the webhook event. Affected Packages / Versions - Package: openclaw (npm) - Affected: < 2026.3.22 - Fixed: = 2026.3.22 - Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked: 2026.3.23-2 Fix Commit(s) - 7ade3553b74ee3f461c4acd216653d5ba411f455 Release Status The fix shipped in v2026.3.22 and remains present in v2026.3.23 and v2026.3.23-2. Code-Level Confirmation - extensions/synology-chat/src/webhook-handler.ts now keeps replies bound to the stable webhook user identifier unless an explicit dangerous opt-in is enabled. - extensions/synology-chat/src/config-schema.ts contains the explicit dangerous opt-in seam instead of silent username rebinding. OpenClaw thanks @nexrin for reporting.
Recommended action: Upgrade to 2026.3.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Before v2026.3.23, the Gateway agent RPC accepted /reset and /new for callers with only operator.write, even though the direct sessions.reset RPC correctly requires operator.admin. Affected Packages / Versions - Package: openclaw (npm) - Affected: < 2026.3.23 - Fixed: = 2026.3.23 - Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked: 2026.3.23-2 Root Cause The vulnerable path lived in src/gateway/server-methods/agent.ts. A /reset or /new message with an explicit sessionKey reached performGatewaySessionReset(...) without enforcing the same operator.admin guard used by sessions.reset. Fix Commit(s) - 50f6a2f136fed85b58548a38f7a3dbb98d2cd1a0 — fix(gateway): require admin for agent session reset Release Status The fix commit is contained in released tags v2026.3.23 and v2026.3.23-2. The latest shipped tag and npm release both include the fix. Code-Level Confirmation - src/gateway/server-methods/agent.ts now…
Recommended action: Upgrade to 2026.3.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Before v2026.3.23, Canvas and A2UI loopback requests could bypass Canvas bearer-or-capability authentication because authorizeCanvasRequest(...) treated isLocalDirectRequest(...) as an unconditional allow path. Affected Packages / Versions - Package: openclaw (npm) - Affected: < 2026.3.23 - Fixed: = 2026.3.23 - Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked: 2026.3.23-2 Root Cause The vulnerable logic lived in src/gateway/server/http-auth.ts. authorizeCanvasRequest(...) returned { ok: true } for local-direct requests before checking bearer authentication or an active node canvas capability, which meant unauthenticated loopback Canvas HTTP and WebSocket requests could succeed. Fix Commit(s) - d5dc6b6573ae489bc7e5651090f4767b93537c9e — fix(gateway): require auth for canvas routes Release Status The fix commit is contained in released tags v2026.3.23 and v2026.3.23-2. The latest shipped tag and npm…
Recommended action: Upgrade to 2026.3.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Before v2026.3.23, the Plivo V2 verification path treated query-only variants of the same signed request as fresh verified work. Plivo V2 signatures authenticate baseUrl + nonce, but the replay key was derived from the full verification URL including the query string, so unsigned query-only changes minted a new verifiedRequestKey. Affected Packages / Versions - Package: openclaw (npm) - Affected: < 2026.3.23 - Fixed: = 2026.3.23 - Latest released tag checked: v2026.3.23-2 (630f1479c44f78484dfa21bb407cbe6f171dac87) - Latest published npm version checked: 2026.3.23-2 Root Cause The vulnerable logic lived in extensions/voice-call/src/webhook-security.ts. V2 signature validation already canonicalized to the base URL without query parameters, but the replay key used the full verificationUrl, letting query-only variants bypass replay identity stability. Fix Commit(s) - b0ce53a79cf63834660270513e26d921899b4e5b — fix(voice-call): stabilize plivo v2 replay keys Release Status The fix…
Recommended action: Upgrade to 2026.3.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw created new session transcript JSONL files with overly broad default permissions in affected releases. On multi-user hosts, other local users or processes could read transcript contents, including secrets that might appear in tool output. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.2.15 - First fixed version: 2026.2.17 - Current latest npm release checked during verification: 2026.3.13 (not affected) Impact Session transcript JSONL files are created under the local OpenClaw session store. In affected releases, newly created transcript files did not force user-only permissions, so transcript contents could be readable by other local users depending on the host environment and umask behavior. Fix New transcript files are now created with 0o600 permissions. Existing transcript permission drift is also remediated by the security audit fix flow. Verified in code: - src/config/sessions/transcript.ts:82 writes new transcript files with mode:…
Recommended action: Upgrade to 2026.2.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw versions <= 2026.3.12 accepted unsanitized iMessage remote attachment paths when staging files over SCP, allowing shell metacharacters in the remote path operand. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.12 - Fixed version: 2026.3.13 Details The vulnerable path was the remote attachment staging flow in src/auto-reply/reply/stage-sandbox-media.ts. When ctx.MediaRemoteHost was set, OpenClaw staged the attachment by spawning /usr/bin/scp against <remoteHost:<remotePath. In affected releases, the remote host was normalized but the remote attachment path was not validated for shell metacharacters before being passed to the SCP remote operand. A sender-controlled iMessage attachment filename containing shell metacharacters could therefore trigger command execution on the configured remote host when remote attachment staging was enabled. This issue is in scope under OpenClaw's trust model because it crosses an inbound content…
Recommended action: Upgrade to 2026.3.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw versions <= 2026.3.12 read and buffered Telegram webhook request bodies before validating x-telegram-bot-api-secret-token. This let unauthenticated callers force up to the configured webhook body limit of pre-auth body I/O and JSON parse work per request. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.12 - Fixed version: 2026.3.13 Details The vulnerable path was the standalone Telegram webhook listener in src/telegram/webhook.ts. In affected releases, the request handler accepted POST requests, called readJsonBodyWithLimit(...), and only then checked the Telegram secret header. Because the secret validation happened after body reading, an unauthenticated caller could make the server spend memory, socket time, and JSON parse work on requests that should have been rejected before any body processing. This issue is in scope under OpenClaw's trust model because the Telegram webhook endpoint accepts untrusted network traffic and the…
Recommended action: Upgrade to 2026.3.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw versions <= 2026.3.12 allowed bootstrap setup codes to be replayed before approval, which could widen the scopes on a pending device pairing request. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.12 - Fixed version: 2026.3.13 Details The vulnerable path was bootstrap token verification in src/infra/device-bootstrap.ts. In affected releases, a valid bootstrap setup code could be verified more than once before the pairing request was approved. That allowed a second verification attempt to mutate a pending device pairing and request broader scopes, including escalation from a lower operator scope to operator.admin, before an approver finalized the pairing. This issue is in scope under OpenClaw's trust model because bootstrap setup codes are an authentication primitive for device pairing and the replay changed the privileges granted to the pending device. Fix openclaw@2026.3.13 makes bootstrap setup codes single-use. Current code…
Recommended action: Upgrade to 2026.3.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
openclaw versions <= 2026.3.12 could include raw Telegram bot tokens in media fetch error strings when inbound Telegram media downloads failed. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.12 - Fixed version: 2026.3.13 Details The vulnerable path was fetchRemoteMedia() in src/media/fetch.ts. In affected releases, fetch and HTTP error paths embedded the original Telegram file URL into MediaFetchError messages. For Telegram media, those URLs can include /file/bot<TOKEN/..., so the resulting error strings could leak bot tokens into logs, console output, or any downstream error surface that rendered the exception text. This issue is in scope under OpenClaw's trust model because the leaked secret is an OpenClaw-operated integration credential, not a user-supplied third-party secret. Fix openclaw@2026.3.13 redacts sensitive media URLs before constructing fetch error messages. Current code routes the source URL and follow-on error paths…
Recommended action: Upgrade to 2026.3.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Zalo webhook handler applied request rate limiting only after webhook authentication succeeded. Requests with an invalid secret returned 401 but did not count against the rate limiter, allowing repeated secret guesses without triggering 429. Impact This made brute-force guessing materially easier for weak but policy-compliant webhook secrets. Once the secret was guessed, an attacker could submit forged Zalo webhook traffic. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Rate limiting now applies before successful authentication is required, closing the pre-auth brute-force gap. Users should update to 2026.3.12 or later and prefer strong webhook secrets.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Feishu webhook mode allowed deployments that configured only verificationToken without encryptKey. In that state, forged inbound events could be accepted because the weaker configuration did not provide the required cryptographic verification boundary. Impact An unauthenticated network attacker who could reach the webhook endpoint could inject forged Feishu events, impersonate senders, and potentially trigger downstream tool execution subject to the local agent policy. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Feishu webhook mode now fails closed unless encryptKey is configured, and the webhook transport rejects missing or invalid signatures before dispatch. Update to 2026.3.12 or later and configure encryptKey for webhook deployments.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The public gateway agent RPC allowed an authenticated operator with operator.write to supply attacker-controlled spawnedBy and workspaceDir values. That let the caller re-root the agent run outside its configured workspace boundary. Impact A non-owner operator could escape the intended workspace boundary and run normal file and exec tools from an arbitrary process-accessible directory. Affected versions openclaw <= 2026.3.8 Patch Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. The gateway now enforces the configured workspace boundary for agent runs regardless of caller-supplied overrides.
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.
A logic flaw in the OpenClaw gateway WebSocket connect path allowed certain device-less shared-token or password-authenticated backend connections to keep client-declared scopes without server-side binding. A shared-authenticated client could present elevated scopes such as operator.admin even though those scopes were not tied to a device identity or an explicitly trusted Control UI path. Impact This crossed the intended authorization boundary and could let a shared-secret-authenticated backend client perform admin-only gateway operations. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. The gateway now clears unbound scopes for non-Control-UI shared-auth connections, and regression tests cover the device-less shared-auth path.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The built-in sessionstatus tool did not enforce the intended session-visibility boundary. A sandboxed subagent could supply another session's sessionKey and inspect or modify state outside its own sandbox scope. Impact This allowed a sandboxed child session to read parent or sibling session data and, in affected releases, update the target session's persisted model override. Affected versions openclaw <= 2026.3.8 Patch Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Session visibility checks now enforce the sandbox boundary before reading or mutating session state.
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.
OpenClaw automatically discovered and loaded plugins from .openclaw/extensions/ inside the current workspace without an explicit trust or install step. A malicious repository could include a crafted workspace plugin that executed as soon as a user ran OpenClaw from that cloned directory. Impact Opening or running OpenClaw in an untrusted repository could lead to arbitrary code execution under the user's account. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Workspace plugin loading now requires explicit trusted state before execution. Users should update to 2026.3.12 or later and avoid running OpenClaw inside untrusted repositories on older releases.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw documented /config and /debug as owner-only commands, but the command handlers checked only whether the sender was command-authorized. A lower-trust sender who was intentionally allowed to run commands could still reach privileged configuration and debugging surfaces. Impact This allowed a non-owner sender to read or change privileged configuration that should have remained restricted to owners. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Owner checks are now enforced for privileged command surfaces, and regression tests cover /config and /debug access control.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
matchesExecAllowlistPattern normalized patterns and targets with lowercasing and compiled glob matching too broadly on POSIX. In addition, the ? wildcard could match /, which allowed matches to cross path segments. Impact These matching rules could overmatch allowlist entries and permit commands or executable paths that an operator did not intend to approve. Affected versions openclaw <= 2026.3.8 Patch Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Exec allowlist matching now respects the intended path semantics, and regression tests cover the POSIX case-folding and slash-crossing cases.
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.
A Feishu reaction-originated synthetic event could misclassify a group conversation as p2p when the inbound reaction payload omitted chattype. Authorization and mention-gating logic keyed off that incorrect chat type and evaluated the event as a direct message instead of a group message. Impact This could bypass groupAllowFrom and requireMention protections for reaction-derived events in Feishu group chats. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Reaction events now preserve the correct group context before authorization and mention-gate evaluation. Users should update to 2026.3.12 or later.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An authorization mismatch in the gateway let an authenticated caller with only operator.write use browser.request to reach browser profile management routes that persist configuration to disk. In practice, this exposed an admin-only configuration write primitive through /profiles/create. Impact A write-scoped operator could create or modify browser profiles and store attacker-chosen remote CDP endpoints without holding operator.admin. Affected versions openclaw <= 2026.3.8 Patch Fixed in openclaw 2026.3.11 and included in later releases such as 2026.3.12. Browser profile creation now requires the correct admin boundary, and regression tests cover the write-vs-admin authorization split.
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.
OpenClaw pairing setup codes generated by /pair and openclaw qr embedded the configured shared gateway token or password directly in the setup payload. Anyone who obtained that code from chat history, logs, screenshots, or copied QR payloads could recover the long-lived shared credential. Impact An attacker with access to a leaked setup code could reuse the shared gateway credential outside the intended one-time pairing flow. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Setup codes now carry short-lived bootstrap tokens that are only valid for the initial device bootstrap exchange. Update to 2026.3.12 or later and rotate any previously exposed shared gateway credentials if setup codes may have leaked.
Recommended action: Upgrade to 2026.3.12 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's Zalouser allowlist mode accepted mutable group names and normalized slugs as authorization matches instead of requiring stable group IDs. In deployments that used name-based channels.zalouser.groups entries together with permissive sender allowlists, a different group could be accepted by reusing the same display name as an allowlisted group. Impact This weakened channel authorization for Zalouser group routing and could allow messages from an unintended group to reach the agent when operators relied on group names instead of stable IDs. Affected versions openclaw <= 2026.3.11 Patch Fixed in openclaw 2026.3.12. Allowlist authorization now matches stable group identifiers, and users should update to 2026.3.12 or later.
Recommended action: Upgrade to 2026.3.12 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, Discord reaction ingestion for guild channels did not enforce the same member users and roles allowlist checks used for normal inbound guild messages. A non-allowlisted guild member could still trigger reaction events that were accepted and queued as trusted system events for the target session. Impact This is an authorization bypass in the Discord allowlist path. Reaction text could be injected into downstream session context even when the reacting guild member was not permitted by the configured users or roles allowlist. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: < 2026.3.11 - Fixed in: 2026.3.11 Technical Details The reaction ingress authorization path enforced DM, group, guild, and channel policy checks, but it did not apply the member-level users and roles allowlist gate that normal guild-message preflight uses. Accepted reactions were then enqueued as trusted system events for the routed session. Fix…
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, local gateway helper credential resolution treated configured but unavailable gateway.auth.token and gateway.auth.password SecretRefs as if they were unset and could fall back to gateway.remote. credentials in local mode. Impact This could cause local CLI and helper paths to select the wrong credential source instead of failing closed for configured local auth SecretRefs. We did not confirm a server-side gateway-authentication boundary bypass for this issue. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details The local-mode fallback logic decided whether remote credential fallback was allowed based on resolved credential values rather than on whether the local auth input was actually configured. A configured-but-unavailable local SecretRef therefore looked "absent" to the helper layer. Fix OpenClaw now tracks whether the local auth input is configured separately…
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, sandbox fs-bridge writes validated the destination before commit, but temporary file creation and population were not pinned to a verified parent directory. A raced parent-path alias change could cause the staged temp file to be created outside the intended writable mount before the final guarded replace step. Impact This is a sandbox boundary bypass affecting integrity and availability within the writable mount scope. Attacker-controlled bytes could be written outside the intended validated path before the final guarded step ran. Affected Packages and Versions - Package: openclaw (npm) - Affected versions: <= 2026.3.8 - Fixed in: 2026.3.11 Technical Details The older staging flow created and wrote the temporary file using target-directory shell path operations before the final replace step revalidated the destination. That meant the last guard protected only the final rename, not the earlier temp-file materialization path. Fix OpenClaw now…
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.