A high-severity CVE in the tool you use to write code every day. The usual playbook (patch, rotate creds, check logs) doesn't quite fit. CVE-2025-53773 isn't a bug in a library your app depends on. It's remote code execution through prompt injection in GitHub Copilot and Visual Studio. The attacker never touches your network. They plant instructions in a file you open, or a README you ask Copilot to summarize, and your IDE runs their code with your permissions. NVD rates it 7.8 (High); in practice it's the kind of finding that should change how we think about the boundary between an AI agent and the host it runs on.
Here's what actually happened, why dev machines are such attractive targets, and what controls ought to sit between any coding assistant and the filesystem.
The Attack: From Prompt to Shell
The core idea is simple. Copilot (and similar agent-style features in VS Code and Visual Studio) can create and modify files in your workspace. Those edits are written to disk immediately—no diff to approve, no "apply" step. The question researchers asked was: what security-relevant settings live in the project folder that the agent can write to?
The answer was .vscode/settings.json. One setting in particular: "chat.tools.autoApprove": true. Turn that on and Copilot enters what's been called "YOLO mode." All confirmations for running terminal commands, browsing the web, or taking other tool actions are disabled. The agent can execute arbitrary shell commands with the developer's privileges, without the user ever clicking "allow."
The exploit chain is prompt injection into content the developer (or Copilot) will read. That content can be a source file, a README, a GitHub issue, or data returned from an MCP server. The injection tells the model to add that line to settings.json—creating the file and directory if they don't exist—and then to run a command. Conditional instructions can pick the payload by OS (Windows vs. macOS vs. Linux). Researchers demonstrated everything from popping a calculator to joining the machine to a remote C2 and downloading malware. The developer might only have asked Copilot to "review this code." No special mode, no sketchy extension. Just open the repo, ask for a review, and the attack runs.
Johann Rehberger (Embrace The Red) and Markus Vervier at Persistent Security found and reported the issue in parallel; Microsoft patched it in August 2025. The fix requires user approval for security-sensitive configuration changes. But the pattern is bigger than one CVE.
Why Developer Workstations Are High-Value Targets
Dev machines are a goldmine. They have access to source code, CI/CD tokens, cloud credentials, SSH keys, and often VPN or internal network access. Compromise one developer and you can push malicious commits, exfiltrate repos, or pivot into build pipelines and production. Traditional phishing and malware have been aimed at this surface for years. What's new is the delivery mechanism: no malicious attachment, no dodgy link. Just a repo the target clones or a file they open, and an AI assistant that obediently reconfigures the environment and runs code.
The wormable angle makes it worse. Once the attacker has code execution, they can embed the same malicious instructions into other files in the project—or in other repos the developer touches. Copilot might be asked to refactor or document code; in doing so it could copy the hidden instructions into new files. Those files get committed and pushed. The next developer who pulls and uses Copilot on that code triggers the same chain. You get propagation through normal collaboration, without a classic worm payload. Persistent Security and others have drawn the comparison to historical worms (Melissa, Code Red, SQL Slammer): trust and connectivity in the development workflow become the propagation vector.
Invisible instructions add another layer. Researchers showed that instructions can be encoded in Unicode so they're not visibly obvious in the file. Not every model or scenario will honor them reliably, and editors may show warnings for unusual characters—but the vector exists. As models and tooling evolve, the bar for stealth will shift.
The Design Flaw: Agents That Modify Their Own Configuration
The deeper issue isn't "Copilot had a bug." It's that an agent was allowed to change settings that govern its own permissions, without a human in the loop. Rehberger had already described this pattern with Amp: when an agent can write to its own configuration or security-relevant files, you get a path to privilege escalation. The agent isn't escaping a sandbox in the classic sense; it's using capabilities it was explicitly given—edit files in the workspace—to remove the remaining guardrails (confirmations) and then run commands. That's a design flaw. It should be caught in threat modeling: can the agent modify anything that changes what it's allowed to do next?
The same pattern shows up elsewhere. .vscode/tasks.json can be abused for code execution. So can adding a malicious MCP server to config. And with multiple agents (Copilot, other coding assistants, custom agents) often sharing project-local config, one compromised agent could overwrite another's allowlists or settings. The fix for CVE-2025-53773 closes one hole; the class of "agent rewrites its own leash" remains something to look for in every agentic system.
What should sit between the AI and the filesystem
What should exist between an AI coding assistant and the developer's machine?
No silent writes to security-sensitive paths. The agent shouldn't be able to persist changes to config that controls its own permissions (e.g. auto-approve, command allowlists, MCP servers) without explicit user approval. Ideally, any file write is presented as a diff and applied only after the user approves. Several editors already do this for edits; the same principle should apply to settings and task definitions that affect execution.
Principle of least privilege for tools. If the agent can run shell commands, that capability should be gated by the same kind of policy you'd use for CI: allowlisted commands or patterns, or approval for anything that isn't in the list. Default to deny for anything that could modify the environment, install software, or exfiltrate data.
Treat project content as untrusted input. Files in the workspace—including READMEs, comments, and docs—are attacker-controllable when the developer clones or opens someone else's project. The model shouldn't treat content from those files as trusted instructions. That's easier said than done (the whole point of Copilot is to reason about project content), but the pipeline should assume that any file content can contain prompt injection and constrain what actions the model can take on the basis of that content. Separation between "reason about this" and "execute on the host" is the goal.
Audit and visibility. Log when the agent modifies config, runs commands, or calls tools. Security teams need to see "Copilot wrote to settings.json" or "Copilot executed curl | sh" so they can detect abuse and investigate. Without that, the agent is a black box with high privilege.
Patching and inventory. Know which developers use Copilot, VS Code, or other agent-enabled IDEs and ensure they're on patched versions. Treat the IDE and its AI features as part of your endpoint and supply-chain story, not just a productivity tool.
After the Patch
CVE-2025-53773 is fixed in the August 2025 updates. If you're on a supported version and current on patches, you're covered for this specific issue. Don't uninstall Copilot. Treat AI-assisted development as a new trust boundary. The assistant has access to your code, your config, and in the worst case your shell. The next CVE might be in another vendor's agent or another config file. The control that generalizes is: agents shouldn't be able to silently elevate their own privileges, and every action that can affect the host should be visible and, where it matters, subject to human approval.
Assessing AI and developer tooling risk or designing controls for agentic systems? We do independent AI risk assessments and governance. Get in touch.