Sandbox escape in Cortex Code CLI enables local code execution

TL;DR — A validation flaw in Cortex Code CLI’s bash tooling can let attacker-crafted content escape the sandbox and run arbitrary commands on a developer’s machine.

What happened

Snowflake’s Cortex Code CLI is a local developer agent that can operate on repositories and run tools (including bash) under a sandbox model.

CVE-2026-6442 describes improper validation of bash commands in Cortex Code CLI versions prior to 1.0.25, where subsequent commands can execute outside the sandbox. The CVE states an attacker can embed specially crafted commands in untrusted content (for example, a malicious repository) and cause the CLI agent to execute arbitrary code on the local device without user consent.

Two operational details matter for responders: exploitation is described as non-deterministic and model-dependent, and the vendor states remediation is automatically applied upon relaunch. This is a concrete example of how agentic developer tooling expands the appsec attack surface: “repo ingestion” plus tool-execution sandboxes creates a supply-chain-like path from untrusted code/content to workstation compromise when sandbox boundaries fail.

Who is impacted

• Developers or CI runners using Snowflake Cortex Code CLI versions prior to 1.0.25.
• Teams that point Cortex Code CLI at untrusted repositories/content (including drive-by “try this repo” workflows), where tool execution is permitted.

What to do now

• Follow vendor remediation guidance.

  "The fix is automatically applied upon relaunch with no user action required."

• Ensure affected endpoints relaunch Cortex Code CLI and verify deployed environments are no longer running an affected build (< 1.0.25).
• Treat this as a potential developer workstation / build-runner compromise path if the CLI was used against untrusted content: review what credentials were accessible to the process (e.g., shell env vars, git credentials, cloud tokens) and rotate per your incident response playbook.
• Add guardrails for similar tools across the fleet: restrict use on untrusted repos, and minimize what secrets and permissions are available to local coding agents and CI agents by default.