All posts
Scope Drift

CVE-2026-70335: Copilot Runs Commands Without the Click

Microsoft's CVE-2026-70335 lets indirect prompt injection drive Copilot agent commands past the per-command confirmation prompt on the developer host

Securityv0 Intelligence Team OWASP: ASI03 sv0 finding: scope_drift
copilot cve-2026-70335 scope-drift prompt-injection vs-code agent-mode

The Incident

Microsoft disclosed CVE-2026-70335 on 2026-08-11 as part of the August 2026 Patch Tuesday. The advisory identifies the flaw as an OS command injection (CWE-78) elevation-of-privilege vulnerability in GitHub Copilot and Visual Studio Code, carrying CVSS 3.1 base 7.8 (AV:L / AC:L / PR:N / UI:R). Microsoft’s own summary describes the chain: an attacker embeds malicious instructions in content that the Copilot agent processes — a web page, a repository file, or a tool response — and when the user runs the agent against that content, the injected instructions cause the agent to run commands on the developer’s machine without prompting for confirmation. Successful exploitation runs arbitrary code in the context of the signed-in user. CVE-2026-70335 was not one of the three zero-days shipped in the August 2026 release; independent Patch Tuesday coverage from Tenable, SecurityWeek, Help Net Security, and BleepingComputer identifies CVE-2026-68820 (a Windows afd.sys use-after-free) as the sole in-the-wild-exploited item in that window. A companion CVE-2026-70336 for Visual Studio Code shipped in the same release. The primary MITRE ATT&CK technique implicated by the delivery path is T1059 (Command and Scripting Interpreter).

The Authority Path That Failed

The identity carrying execution authority is the signed-in developer running Visual Studio Code with GitHub Copilot in agent mode. The scope that identity holds is the developer’s full OS shell context — every file the workstation can read, every credential on disk (~/.aws/credentials, cloud SDK caches, SSH keys, .env files), every authenticated CLI, and every source repository. Copilot’s agent-mode code-execution tool inherits every one of those permissions, but the operator’s intended authorization boundary was never “the tool is attached” — it was “each shell command surfaces a confirmation prompt the human clicks before it runs.”

The trust anchor that failed was that per-command confirmation prompt. Once attacker-controlled text — sitting in a web page a browsing tool fetched, a README the agent opened, a tool response an MCP server returned — reached the agent’s context and read as instructions, the model routed shell commands through a code path that never fired the prompt. The exercised scope collapsed to “any command any tool response asks for,” while the operator only ever attested to “commands I clicked Approve on.” One year earlier, CVE-2025-53773 (disclosed by Johann Rehberger, published 2025-08-12) demonstrated the same class in the same product via the autoApprove / YOLO-mode configuration — the second time in twelve months that the confirmation-prompt anchor has proven dissolvable in Copilot agent mode.

SecurityV0 Perspective

This is scope_drift (ASI03). The Copilot agent identity, the shell tool, and the developer’s ambient OS permissions were all sanctioned; the specific action the agent took — running a command the operator never clicked Approve on — was not. The pattern generalizes past Copilot: any AI-coding agent whose only authorization control on code execution is a runtime confirmation UI is one indirect-prompt-injection payload away from the same held-versus-exercised gap.

What To Do

  • Patch Visual Studio Code and the Copilot extension to the versions Microsoft ships with the August 2026 Patch Tuesday release. Track the fixed build numbers on the MSRC advisories for CVE-2026-70335 and its companion CVE-2026-70336; both cover the same product surface, and both should reach the developer fleet in one push rather than staggered rollouts.
  • Treat “per-command confirmation” as a UX signal, not an authorization control, wherever an AI coding agent can reach a shell. For every agent your team runs in agent mode (Copilot, Cursor, Claude Code, Gemini Code Assist), enumerate the tools that can execute code and confirm that at least one authorization gate above the runtime UI prompt — a signed operator allowlist, a per-repository policy, an out-of-band approval — sits between the agent and the shell. If the only gate is the click, treat that agent’s tool inventory as ambient shell access whenever the workstation ingests untrusted content.
  • Withhold high-value credentials from the developer profile that runs an agent-mode assistant. Cloud CLI credentials, production database keys, long-lived personal access tokens, and password-manager sessions should not be present in the same OS profile the agent’s shell tool inherits. Move them to a segregated profile the agent cannot reach, or gate them behind hardware-backed prompts that a silently-dispatched shell command cannot satisfy.
  • Log every shell command an agent dispatches with the content chunk that was in the model’s context when the decision was made. At minimum, retain agent identity, command executed, working directory, the URL or file path of untrusted content the agent had just processed, and whether a user-confirmation event fired for that specific command. Without that record, “did the developer approve this, or did an email tell the agent to run it?” has no deterministic post-incident answer.
  • Rotate any credential exposed to a Copilot agent-mode session during an incident window on an unpatched build. Any workstation that ran an unpatched Copilot agent while it processed untrusted content — a web page fetched by a browsing tool, a repository the developer cloned, an MCP tool response — should be treated as a compromised host: rotate the AWS, Azure, and GCP CLI credentials, the developer’s PAT, any tokens exported into shell history, and any SSH keys the process could read.

Sources

All posts