A Cursor Auto-Run Mode issue described by Docker shows how an approved-command policy can fail when it evaluates the visible command but not the execution environment around it. The incident involved environment-variable changes made through shell built-ins that were not displayed in the allowlist or sent for approval. A later command that appeared ordinary could then execute attacker-controlled code with the developer’s permissions.
The case is relevant beyond one editor or one product. Coding agents routinely read repositories, issue text, dependency files, and project instructions. If those inputs can influence the agent, command approval, workspace access, credentials, and network connectivity all become part of the threat model.
What changed in the Cursor incident
In its account of the incident, Docker identifies the issue as CVE-2026-22708, disclosed by Pillar Security on January 14, 2026. Docker describes it as a high-severity Cursor flaw patched in Cursor 2.3. The supplied evidence for the CVE identifier, affected behavior, and remediation comes primarily from Docker’s announcement; an independent Cursor or Pillar advisory was not supplied.
The described problem affected Auto-Run Mode. Shell built-ins such as export, typeset, and declare could alter environment variables without appearing in the enabled command allowlist or requesting approval. That created a path where a later visible command, such as git branch or python3 script.py, could run attacker-controlled code.
The attack did not require memory corruption or privilege escalation. According to Docker’s account, the payload ran with the developer’s existing permissions. It could begin with content the agent was able to read, including a README, dependency, or issue comment. The described chain also included variants that wrote to ~/.zshrc and ended with SSH private keys leaving the machine.
Docker says the behavior could work even with an empty allowlist. Cursor changed its parser so that anything it cannot classify requires approval. That change addresses the described command-classification behavior, but it does not make approval controls a complete containment boundary.
Why approval alone is not enough
Cursor’s current security documentation describes Allowlist mode as permitting allowlisted actions without approval. It also documents sandboxing as a separate layer for supported shell commands. Depending on the command and configuration, sandboxing can restrict access to protected files, writes outside approved paths, or arbitrary network destinations.
The distinction matters: a run mode decides when an action requires approval, while sandboxing limits what an action can reach. Cursor also states that Auto-review is a classifier-based control and is not a security boundary because the classifier can make mistakes. Browser use, file deletion, and operations involving external files have additional protections, while team settings can control available modes and sandbox networking rules.
For administrators, the practical lesson is to model the full execution path rather than asking only whether a command name is approved. The environment, inherited variables, shell behavior, repository contents, network destinations, credentials, and host integrations can all change the consequences of an apparently harmless command.
What Docker Sandboxes isolate—and what they share
Docker Sandboxes run agents inside microVMs with separate kernels and filesystems. The agent has full control inside the virtual machine, including sudo access, so the sandbox is not intended to make agent behavior trustworthy. Its purpose is to change what the agent can reach outside that environment.
According to Docker’s security documentation, access to the host is limited to explicitly shared resources. Those boundaries can include the workspace, proxied network access, credentials, shared skills, and MCP gateway traffic. Each shared capability therefore needs to be reviewed as part of the security boundary.
Workspace selection is especially important. Direct workspace mode shares the host working tree read-write, with changes visible on the host in real time. Docker warns that this also exposes implicitly executed resources such as Git hooks, CI configuration, IDE task settings, AI project settings, Makefiles, and package.json scripts. Git hooks may not appear in normal git diff output.
Clone mode provides a private clone and mounts the repository read-only, while mountless mode avoids a host workspace mount. Those options reduce the specific exposure created by a live, read-write working tree, although they do not eliminate the need to review other shared capabilities.
Networking is also proxied and policy-controlled. Docker documents outbound TCP access through the host proxy, with direct external UDP and ICMP blocked. The sandbox does not receive direct access to the host network or Docker daemon. SSH-agent forwarding can support ordinary SSH work when network rules permit the required destination and port, but forwarded credentials remain usable capabilities.
Docker also warns that shared agent skills are mounted read-write from a host-side store unless users opt out. Participating sandboxes therefore share a trust boundary for those skills. Local stdio MCP servers run outside the sandbox on the host and should be treated as trusted host integrations; remote MCP access is brokered through a host-side gateway.
Editor integration and kits have different availability
Docker’s editor integration documentation labels the integration generally available. It lists Cursor as a supported editor integration and requires Docker Sandboxes 0.37.0 or later, the sbx CLI, an SSH client, and editor support for remote-over-SSH. The documented setup uses sbx setup ssh, managed SSH configuration, and an active Docker login. Connections terminate at the local sandbox daemon through a local socket or named pipe rather than an SSH server inside the sandbox.
The supplied documentation does not include the complete Cursor-specific Remote–SSH procedure or establish compatibility across every Cursor edition, operating system, or deployment configuration. Docker’s announcement also identifies Cursor Remote–SSH support as required for the described workflow.
Docker kits are a separate feature and are labeled Early Access and experimental. A kit’s spec.yaml can define tools, environment variables, proxied credentials, network rules, files, startup commands, and agent instructions. Kits may extend an existing agent or define an agent, image, entrypoint, network policies, and other requirements from scratch.
Kit documentation describes allow and deny domain rules, with deny taking precedence when both match. Organization governance can control allow rules, while kit deny rules continue to restrict access. Credentials remain on the host and are injected through a proxy; raw secret values should not be placed directly in environment variables because they would be visible inside the VM.
Kits can be validated, signed, and verified with cosign-compatible Sigstore workflows. Required-signature policies can reject unsigned or untrusted kits. However, signatures do not cover mutable dependencies such as image tags or content downloaded by install and startup commands. Those dependencies must be pinned separately when reproducibility or supply-chain integrity matters.
What you should do
- Update Cursor. Use the patched Cursor version identified by Docker’s announcement, while recognizing that the supplied material does not independently verify the full patch scope.
- Do not rely on approval classifiers alone. Treat allowlists and Auto-review as policy controls, not as complete security boundaries for untrusted agent work.
- Reduce workspace exposure. Prefer clone or mountless sandbox modes when a live host working tree is not required. Review Git hooks and other implicitly executed project files separately.
- Minimize capabilities. Review network rules, SSH-agent forwarding, proxied credentials, shared skills, and MCP integrations. Allow only the destinations and credentials required for the task.
- Review kits as code. Use versioned and diffable kit artifacts, validate them, and apply signing and verification where appropriate. Pin mutable images and downloaded dependencies when the workflow requires stronger reproducibility.
- Keep host integrations trusted. Local stdio MCP servers operate outside the sandbox on the host, so evaluate their permissions independently of the microVM boundary.
Important limitations
Isolation changes the reachable impact of an unsafe agent action; it does not make injected instructions safe or guarantee that compromise is impossible. Credentials, live workspace mounts, network access, shared skills, and host-side integrations remain explicit boundary crossings.
Docker’s editor integration is documented as generally available, but kits remain experimental and may change. The supplied sources do not establish pricing, licensing, performance, broad platform compatibility, or complete audit-log behavior. They also do not show that Docker Sandboxes, Cursor controls, or kit signatures prevent every unsafe action or escape.
