Workspace-File-Write Attack

A Workspace-File-Write Attack is an attack pattern where an AI agent is induced to write a file in the host workspace whose content is then auto-applied as configuration or instruction by the agent runtime, chaining prompt injection to permanent reconfiguration or remote code execution. The pattern is the mechanism behind CVE-2025-54135 ("CurXecute") in Cursor IDE — analysed in detail in the Cursor IDE MCP CVEs writeup — and applies to every IDE-embedded agent that auto-applies workspace files as agent rules.

The exploit chain works in five steps. First, the agent processes an input the attacker controls — a document the user reads, a webpage the agent fetches, a tool output the agent receives. Second, the input contains a prompt-injection payload directing the agent to "create" or "fix" a missing file in the workspace. Third, the agent issues a workspace-file-write through its standard tool surface; the runtime performs the write without surfacing the action to the user. Fourth, the written file is one the runtime auto-applies as agent configuration (a .cursor/rules file, a .aider.conf file, an MCP host's local manifest fragment). Fifth, on the next agent turn, the runtime reads the new configuration and executes attacker-chosen actions — up to and including arbitrary command execution via the runtime's terminal or exec primitives.

Why the Pattern Works

Two design choices combine to produce the vulnerability. The first is silent file write: the agent runtime performs workspace mutations through its standard tool surface without explicit per-write user confirmation. This is convenient — developers do not want a confirmation prompt for every package.json edit — but it removes the user-attention checkpoint that would otherwise catch a malicious file creation. The second is auto-applied workspace configuration: certain files in the workspace, when present, are read by the runtime and applied as agent rules without any further authorisation. Either choice alone is defensible; the combination produces an attack primitive that any successful prompt injection can chain to permanent compromise.

Defensive Patterns

The structural fix is to break either link of the chain. The conservative break: never auto-write workspace files without explicit user confirmation, especially configuration files. The more nuanced break: restrict the set of workspace paths that can influence agent configuration to a small explicit allowlist. Unknown configuration files should be ignored, not auto-applied. Both layers should be in place — defence in depth.

Operationally, the controls that detect a workspace-file-write attack in progress include logging every workspace mutation with file path, content, and the prompt context that produced it; flagging any creation of a file the runtime would auto-apply as configuration; and requiring an explicit prompt to the user before any workspace-write that touches an auto-applied path.

For Web3 developers specifically, the additional rule applies: agent runtimes that can access wallet keystores or signing-related session tokens must not auto-apply ANY workspace configuration files. The composition is too dangerous to gate with confirmation; it must be impossible at the architecture layer. For deeper guidance on IDE-embedded agent threat models, see the MCP Security Audit service description.