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.
OpenClaw supports Discord allowlists using either user IDs or names/tags. Name/tag matching depends on slug normalization, so different user tags can collide to the same slug and unintentionally satisfy a name-based allowlist entry. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.2.21-2 - Patched versions: = 2026.2.22 What Changed - openclaw security audit now warns on Discord name/tag allowlist entries (DM allowlists, guild/channel users, and pairing-store entries). - Runtime authorization now prefers resolved user IDs when a configured name/tag can be resolved, without rewriting config files on disk. - Name-based entries remain supported for compatibility. Recommendations - Prefer stable Discord user IDs for security-sensitive allowlists. - Run openclaw security audit and address warnings where practical. Fix Commit(s) - f97c45c5b5e0698b6667bb5f6badc0cac7dabd12 - 747bb581b3f2264495e1fec5a0727d9f2ca1b6f1 OpenClaw thanks @tdjackey for reporting.
Recommended action: Upgrade to 2026.2.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected releases, when an operator explicitly enabled gateway.controlUi.allowInsecureAuth: true and exposed the gateway over plaintext HTTP, Control UI authentication could permit privileged operator access without the intended device identity + pairing guarantees. This required an insecure deployment choice and credential exposure risk (for example, plaintext transit or prior token leak). It was fixed on main in commit 40a292619e1f2be3a3b1db663d7494c9c2dc0abf (PR #20684). Affected Packages / Versions - Package: openclaw (npm) - Affected published versions: <= 2026.2.19-2 - Planned patched version: 2026.2.21 Impact In these explicitly insecure deployments, an attacker with leaked/intercepted credentials could obtain high-privilege Control UI access. Fix Commit(s) - 40a292619e1f2be3a3b1db663d7494c9c2dc0abf (merged 2026-02-20) OpenClaw thanks @Vasco0x4 for reporting.
Recommended action: Upgrade to 2026.2.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw's SSRF IP classifier did not treat IPv6 multicast literals (ff00::/8) as blocked/private-internal. This allowed literal multicast hosts to pass SSRF preflight checks. Impact A bypass in address classification existed for IPv6 multicast literals. OpenClaw's network fetch/navigation paths are constrained to HTTP/HTTPS and this was triaged as low-severity defense-in-depth hardening. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.2.24 - Patched versions: = 2026.2.25 Technical Details The IPv6 private/internal range set omitted multicast, so addresses like ff02::1 and ff05::1:3 were not classified as blocked by the shared SSRF classifier. Fix Commit(s) - baf656bc6fd7f83b6033e6dbc2548ec75028641f Release Process Note patchedversions is pre-set to the planned next npm release (2026.2.25). Once that release is published on npm, the advisory is published. OpenClaw thanks @zpbrent for reporting.
Recommended action: Upgrade to 2026.2.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw exec allowlist/safeBins policy could be bypassed with attached short-option payloads (for example sort -o/tmp/poc), enabling file-write operations while still satisfying safeBins checks. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: <= 2026.2.17 - Latest published vulnerable version: 2026.2.17 - Patched in: 2026.2.19 Impact When tools.exec.security=allowlist and tools.exec.safeBins included affected binaries, attached short-option payloads could bypass safeBins argument validation and permit file-write behavior that should have been denied. Fix Commit(s) - cfe8457a0f4aae5324daec261d3b0aad1461a4bc - bafdbb6f112409a65decd3d4e7350fbd637c7754 - fec48a5006eab37c6a5821726ccaeec886486b13 OpenClaw thanks @FailButWin and @Redgrave961 for reporting.
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When the optional Chrome extension relay is enabled, /extension accepted unauthenticated WebSocket upgrades while /json/ and /cdp required auth. Affected Packages / Versions - Package: openclaw (npm) - Affected: <= 2026.2.17 - Latest published npm version at triage time: 2026.2.17 Impact This is a local-only issue on loopback (127.0.0.1) and only applies when the extension relay feature is in use. A local process on the same machine could connect to /extension without the token and interfere with extension-relay behavior. No remote network exploit path is involved. Fix - Require gateway-token auth on both /extension and /cdp relay WebSocket endpoints. - Keep loopback/origin checks as defense-in-depth, not as authentication. - Use one token path in setup: gateway.auth.token / OPENCLAWGATEWAYTOKEN. Fix Commit(s) - 7e54b6c96feb1a5c30884f2b32037b8dadd0e532 OpenClaw thanks @tdjackey for reporting.
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Feishu allowlist authorization could be bypassed by display-name collision. Details channels.feishu.allowFrom is documented as an ID-based allowlist (openid list), but Feishu policy matching accepted mutable sender display names in the same namespace. An attacker could set a display name equal to an allowlisted ID string and pass authorization checks. The fix enforces ID-only matching for Feishu allowlist checks, normalizes Feishu ID prefixes during comparison, and ignores mutable display names for authorization. Impact Deployments using Feishu allowlist-based authorization could incorrectly authorize non-allowlisted senders when a colliding display name was used. Affected Packages / Versions - Package: openclaw (npm) - Latest published version at triage time: 2026.2.21-2 - Affected range: <= 2026.2.21-2 - Planned patched version: = 2026.2.22 Fix Commit(s) - 4ed87a667263ed2d422b9d5d5a5d326e099f92c7 Release Process Note patchedversions is pre-set to the planned next release (=…
Recommended action: Upgrade to 2026.2.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenClaw's macOS node-host path, system.run allowlist parsing in security=allowlist mode failed to reject command substitution tokens when they appeared inside double-quoted shell text. Because of that gap, payloads like echo "ok $(id)" could be treated as allowlist hits (first executable token echo) while still executing non-allowlisted subcommands through shell substitution. Affected Packages / Versions - Package: npm openclaw - Latest published affected version: 2026.2.21-2 - Affected range: <= 2026.2.21-2 - Patched version (planned next release): 2026.2.22 Notes: - Default installs are not affected (security=deny by default). - The issue requires opting into security=allowlist on the macOS node-host path. Impact Approval/authorization bypass in allowlist mode that can lead to unintended command execution on the node host. Preconditions - Target uses macOS node-host / companion-app execution path. - Exec approvals set to security=allowlist. - Ask mode is on-miss or off.…
Recommended action: Upgrade to 2026.2.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw shell-env fallback trusted startup environment values and could execute attacker-influenced login-shell startup paths before loading env keys. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: = 2026.1.5 and <= 2026.2.21-2 - Fixed on main: 9363c320d8ffe29290906752fab92621da02c3f7 - Planned patched release version (pre-set): 2026.2.22 Details The vulnerable chain was in the shell-env fallback path: 1. src/infra/shell-env.ts - resolveShell(env) trusted env.SHELL when set. - execLoginShellEnvZero(...) executed ${SHELL} -l -c "env -0" with inherited runtime env. 2. src/config/io.ts - Config env values were applied before shell fallback execution. 3. src/config/env-vars.ts / env policy coverage - SHELL handling was hardened, but startup-path selectors (HOME, ZDOTDIR) still needed explicit blocking in config env ingestion and sanitization for shell fallback execution. With env/config influence, this could trigger unintended command execution in…
Recommended action: Upgrade to 2026.2.22 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw plugins/extensions run in-process and are treated as trusted code. This advisory tracks trust-boundary clarification around plugin runtime command execution (runtime.system.runCommandWithTimeout). Impact Plugins already execute with the same OS privileges as the OpenClaw process. Exposing runtime command helpers does not cross an additional sandbox boundary. Affected Packages / Versions - Package: openclaw (npm) - Latest published version reviewed: 2026.2.17 - Affected range for this advisory record: <= 2026.2.17 - Planned patched version metadata: 2026.2.19 (next release line) Fix Commit(s) - 2e421f32dfc589c02706265fd3c3137ffc06c4b1 Remediation - Install only trusted plugins. - Use plugins.allow to pin explicit trusted plugin IDs. - SECURITY.md now explicitly documents that plugin runtime helpers are convenience APIs, not a sandbox boundary. OpenClaw thanks @markmusson for reporting.
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A client using shared gateway auth could attach an unpaired device identity and request elevated operator scopes (including operator.admin) before pairing approval, enabling privilege escalation. Impact Attackers with valid shared gateway auth could self-assign higher operator scopes by presenting a self-signed, unpaired device identity. Affected Packages / Versions - Package: openclaw (npm) - Affected: = 2026.2.22 <= 2026.2.24 - Latest published npm at triage time: 2026.2.24 - Planned patched release: 2026.2.25 Remediation Require pairing for operator device-identity sessions authenticated with shared token/password auth (except existing control-ui trusted-proxy/control-ui bypass policy paths). Fix Commit(s) - 8d1481cb4a9d31bd617e52dc8c392c35689d9dea Release Process Note patchedversions is pre-set to the release (= 2026.2.25). Advisory published with npm release 2026.2.25. OpenClaw thanks @tdjackey for reporting.
Recommended action: Upgrade to 2026.2.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact assertBrowserNavigationAllowed() validated only http:/https: network targets but implicitly allowed other schemes. An authenticated gateway user could navigate browser sessions to file:// URLs and read local files via browser snapshot/extraction flows. Affected Component - src/browser/navigation-guard.ts Technical Reproduction 1. Authenticate to a gateway that has browser tooling enabled. 2. Invoke browser navigation with a file:// URL (for example file:///etc/passwd). 3. Read page content through browser snapshot/extract actions. Demonstrated Impact An attacker with valid gateway credentials and browser-tool access can exfiltrate local files readable by the OpenClaw process user (for example config/secrets in that user context). Environment - OpenClaw browser tool enabled - Attacker has authenticated access capable of invoking browser actions Remediation Advice Reject unsupported navigation schemes and allow only explicitly safe non-network URLs. OpenClaw now blocks…
Recommended action: Upgrade to 2026.2.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
OpenClaw Windows Scheduled Task script generation allowed unsafe argument handling in generated gateway.cmd files. In vulnerable versions, cmd metacharacter-only values could be emitted without safe quoting/escaping, which could lead to unintended command execution when the scheduled task runs. Details The issue affected Windows daemon startup script generation in src/daemon/schtasks.ts. Vulnerable behavior included: - Incomplete cmd argument quoting for metacharacter-only values. - Incomplete handling of cmd expansion-sensitive characters in script arguments. - Missing CR/LF guards for script-rendered fields. The fix hardens Windows script generation by: - Separating schtasks argument quoting from batch script argument quoting. - Quoting cmd metacharacter arguments and escaping % / ! expansion cases. - Rejecting CR/LF in command arguments, task descriptions, and rendered environment assignments. - Adding regression tests for metacharacter and line-break injection paths.…
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In some opt-in sandbox configurations, the experimental applypatch tool did not consistently apply workspace-only checks to mounted paths (for example /agent/...). Impact This does not affect default installs. Default posture: - agents.defaults.sandbox.mode=off (sandbox disabled by default) - tools.exec.applyPatch.enabled=false (experimental tool disabled by default) This behavior applies only when all of the following are enabled/configured: - sandbox mode, - experimental applypatch, - workspace-only expectations (tools.fs.workspaceOnly=true and/or tools.exec.applyPatch.workspaceOnly=true), - and writable mounts outside workspace. Under that opt-in setup, applypatch operations could target mounted paths outside the workspace root. Affected Packages / Versions - Package: openclaw (npm) - Affected published versions: <= 2026.2.22-2 - Fixed in code on main: commit 6634030be31e1a1842967df046c2f2e47490e6bf - Patched release: 2026.2.23 Technical Details In the sandbox path flow,…
Recommended action: Upgrade to 2026.2.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In openclaw MS Teams file-consent flow, pending uploads were authorized by uploadId alone. fileConsent/invoke did not verify the invoke conversation against the conversation that created the pending upload. Impact An attacker who obtained a valid uploadId within TTL could trigger cross-conversation upload completion (accept path) or cancel a victim pending upload (decline path). Technical Details - Pending uploads stored conversationId, but invoke handling consumed by uploadId only. - The invoke path did not enforce conversation binding before uploadToConsentUrl(...) and pending-upload removal. - Fix binds accept/decline handling to normalized conversation id match before consuming pending upload state. Affected Packages / Versions - Package: openclaw (npm) - Latest published npm version (as of February 26, 2026): 2026.2.24 - Vulnerable range: <= 2026.2.24 - Patched in release: 2026.2.25 Remediation Upgrade to openclaw 2026.2.25 (or later) once published. Fix Commit(s) -…
Recommended action: Upgrade to 2026.2.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In authenticated non-owner DM sessions, a narrow tool-invocation path could reach broader-than-intended owner-only gateway actions. Impact This requires an authenticated non-owner sender in a DM session and a specific tool invocation path. No unauthenticated access is involved, and this does not provide direct code execution by itself. Root Cause - Some gateway call paths were still using broader default scopes instead of method-level least-privilege scopes. - Owner-only enforcement depended on tool-name checks and was not consistently metadata-driven across all call paths. Affected Packages / Versions - Package: openclaw (npm) - Affected: <= 2026.2.17 (latest published npm version as of February 19, 2026) - Patched: 2026.2.19 Remediation - Refactored gateway method scope mapping to a data-driven table and added guard tests to ensure all exposed core gateway methods stay classified. - Centralized owner-only enforcement in tool policy wrappers and tool metadata. - Marked…
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
shell-env fallback trusted prefix-based executable paths for $SHELL, allowing execution of attacker-controlled binaries in local/runtime-env influence scenarios. Details In affected versions, shell selection accepted either: 1. a shell listed in /etc/shells, or 2. any executable under hardcoded trusted prefixes (/bin, /usr/bin, /usr/local/bin, /opt/homebrew/bin, /run/current-system/sw/bin). The selected shell was then executed as a login shell (-l -c 'env -0') for PATH/environment probing. On systems where a trusted-prefix directory is writable (for example common Homebrew layouts under /opt/homebrew/bin) and runtime $SHELL can be influenced, this enabled attacker-controlled binary execution in OpenClaw process context. The fix removes the trusted-prefix executable fallback and now trusts only shells explicitly registered in /etc/shells; otherwise it falls back to /bin/sh. Affected Packages / Versions - Package: openclaw (npm) - Affected versions: = 2026.2.22, <= 2026.2.22-2…
Recommended action: Upgrade to 2026.2.23 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
BlueBubbles webhook auth in the optional beta iMessage plugin allowed a passwordless fallback path. In some reverse-proxy/local routing setups, this could allow unauthenticated webhook events. Affected Component and Scope - Component: extensions/bluebubbles webhook handler - Scope: only deployments using the optional BlueBubbles plugin where webhook password auth was not configured for incoming webhook events Affected Packages / Versions - Package: openclaw/openclaw (npm) - Latest published npm version at triage time (2026-02-21): 2026.2.19-2 - Affected structured range: <=2026.2.19-2 - Fixed on main; planned patched release: 2026.2.21 (=2026.2.21) Details The vulnerable implementation had multiple auth branches, including a passwordless fallback with loopback/proxy heuristics. The fix now uses one authentication codepath: - inbound webhook token/guid must match channels.bluebubbles.password - webhook target matching is consolidated to shared plugin-sdk logic - BlueBubbles…
Recommended action: Upgrade to 2026.2.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Remote iMessage attachment fetches used SCP with trust-on-first-use host-key behavior and accepted unvalidated remote host tokens. Before the fix: - SCP used StrictHostKeyChecking=accept-new in the remote attachment path. - channels.imessage.remoteHost was not validated as a strict SSH host token. Impact In remote iMessage deployments that use SCP attachment fetching, a first-connection MITM/DNS-poisoning scenario could cause the wrong host key to be trusted. Unsafe remote host token values could also alter SCP argument semantics. Affected Packages / Versions - Package: openclaw (npm) - Latest published npm version currently affected: 2026.2.17 - Vulnerable range (structured field): <= 2026.2.17 - Patched version (pre-set for next release): = 2026.2.19 Fix The fix hardens remote attachment SSH/SCP handling by: - requiring StrictHostKeyChecking=yes for SCP and SSH tunnel paths, - adding strict remoteHost normalization/validation, - adding -- argument barrier for SCP remote…
Recommended action: Upgrade to 2026.2.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In openclaw<=2026.2.23, safe-bin trust in allowlist mode relied on static default trusted directories that included package-manager paths (notably /opt/homebrew/bin and /usr/local/bin). When a same-name binary (for example jq) is placed in one of those trusted default directories, safe-bin evaluation can be satisfied and execute the attacker-controlled binary. Impact This is an exec allowlist safeBins policy bypass that can lead to command execution in the OpenClaw runtime context. Severity is set to Medium given the required ability to write into trusted host binary directories. Affected Packages / Versions - Package: openclaw (npm) - Vulnerable versions: <= 2026.2.23 - Patched versions: = 2026.2.24 (planned next npm release) - Latest published npm version at triage time (2026-02-24): 2026.2.23 Root Cause - Default safe-bin trusted directories included package-manager/user-managed paths. - Trust decision was directory-membership only for resolved executable paths.…
Recommended action: Upgrade to 2026.2.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The tar.bz2 installer path in src/agents/skills-install-download.ts used shell tar preflight/extract logic that did not share the same hardening guarantees as the centralized archive extractor. This allowed crafted .tar.bz2 archives to bypass special-entry blocking and extracted-size guardrails enforced on other archive paths, causing local availability impact during skill install. Affected Packages / Versions - Package: openclaw (npm) - Latest published at triage time: 2026.3.1 - Affected range: <= 2026.3.1 - Patched in: 2026.3.2 (released) Impact Local DoS / availability impact when processing untrusted .tar.bz2 skill archives. Fix Commit(s) - 0dbb92dd2bcf9a32379d11c0f11ed016669dae3e Related advisories - Canonical overlap (closed): GHSA-3pj7-x8jr-jvj8 - Duplicate variant (closed): GHSA-rgr7-g85h-6v82
Recommended action: Upgrade to 2026.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In openclaw@2026.3.1, the Discord voice transcript path called agentCommand(...) without senderIsOwner, and agentCommand defaults missing senderIsOwner to true. This could allow a non-owner voice participant in the same channel to reach owner-only tool surfaces (gateway, cron) during voice transcript turns. Security model note OpenClaw’s documented trust model is a personal assistant model (one trusted operator), not an adversarial multi-user boundary. - OpenClaw does not treat one shared gateway/chat surface as a hardened per-user auth boundary. - Mixed-trust deployments (mutually untrusted users sharing one gateway/channel) are outside recommended deployment boundaries. This report is treated as a valid hardening/authorization bug because owner-only tool policy should still be applied consistently across chat-driven turns, including Discord voice transcript ingress. Details Relevant path: 1. Voice transcript run omitted senderIsOwner in Discord voice manager. 2. Missing…
Recommended action: Upgrade to 2026.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Sandboxed sessionsspawn(runtime="acp") could bypass sandbox inheritance and initialize host-side ACP runtime. The fix now fail-closes ACP spawn from sandboxed requester sessions and rejects sandbox="require" for runtime="acp". Affected Packages / Versions - Package: openclaw (npm) - Latest published npm version at triage time: 2026.3.1 (March 2, 2026) - Vulnerable range: <=2026.3.1 - Patched release: 2026.3.2 (released) Technical Details - Root cause: runtime="subagent" enforced sandbox inheritance, while runtime="acp" did not enforce equivalent sandbox/runtime checks. - Security impact: sandbox-boundary bypass into host-side ACP initialization. - Fixed behavior: - deny ACP spawn when requester runtime is sandboxed - deny sessionsspawn with runtime="acp", sandbox="require" - align sandboxed prompt guidance to avoid advertising blocked ACP paths Fix Commit(s) - ac11f0af731d41743ba02d8595f4d0fe747336e3 - c703aa0fe92df9fb71cf254fc46991e05fba2114
Recommended action: Upgrade to 2026.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
(Updated March 2, 2026) Encoded alternate-path requests could bypass plugin route auth checks for /api/channels/ due to canonicalization depth mismatch in vulnerable builds. Affected Packages / Versions - Package: openclaw (npm) - Latest published vulnerable version: 2026.3.1 - Affected range: <= 2026.3.1 - Patched release: 2026.3.2 (patchedversions: = 2026.3.2) Technical Details In affected versions, plugin auth-path classification and route-path canonicalization could diverge for deeply encoded slash variants (for example multi-encoded %2f). That mismatch allowed alternate encoded paths to evade protected-prefix auth checks while still resolving to /api/channels/... in plugin route handling. The fix set hardens this class of issue by: - canonicalizing route paths to a bounded fixpoint, - failing closed on malformed or unresolved canonicalization depth, - requiring explicit plugin-route auth contracts (no implicit auth default), - enforcing route ownership/conflict guards…
Recommended action: Upgrade to 2026.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In OpenClaw <= 2026.2.24, Discord direct-message reaction notifications did not consistently apply the same DM authorization checks (dmPolicy / allowFrom) that are enforced for normal DM message ingress. In restrictive DM setups, a non-allowlisted Discord user who can react to a bot-authored DM message could still enqueue a reaction-derived system event in the session. This is a reaction-only ingress inconsistency. By itself it does not directly execute commands; practical impact depends on downstream automation/tool policy. Details The DM message path already enforces dmPolicy/allowFrom authorization, but the DM reaction-notification path previously allowed event enqueue under reaction mode checks without that same authorization gate. Fix in main aligns reaction ingress with normal message preflight for Discord DM/group-DM/guild policy boundaries and applies equivalent DM reaction authorization hardening for Slack to keep channel behavior consistent. Affected Packages /…
Recommended action: Upgrade to 2026.2.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ZIP extraction in OpenClaw could be raced into writing outside the intended destination directory via parent-directory symlink rebind between validation and write. Affected Packages / Versions - Package: openclaw (npm) - Vulnerable versions: <= 2026.3.1 - Latest published vulnerable version confirmed: 2026.3.1 (npm as of 2026-03-02) - Patched version: 2026.3.2 (released) Technical Details In src/infra/archive.ts, ZIP extraction previously validated output paths, then later opened/truncated the destination path in a separate step. A local race on parent-directory symlink state could redirect the final write outside the extraction root. The fix hardens ZIP writes by binding writes to the opened file handle identity and avoiding the pre-write truncate race path, with shared fd realpath verification in src/infra/fs-safe.ts and regression coverage in src/infra/archive.test.ts. Fix Commit(s) - 7dac9b05dd9d38dd3929637f26fa356fd8bdd107
Recommended action: Upgrade to 2026.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.