Validated Research Published: Aug 5, 2026

IDEsaster Shows How Agent File Writes Can Activate Trusted IDE Features

IDEsaster is a cross-product vulnerability class in which prompt injection does not need a dangerous agent tool to finish the attack. The agent uses ordinary file access, then the underlying IDE automatically loads a remote schema, changes a workspace boundary, or executes a configured program. The research reported more than 30 vulnerabilities and 24 CVEs across over ten products. Defenders must therefore constrain the combined authority of the agent, IDE, native bridge, and background features.

Indirect Prompt InjectionRemote Code ExecutionTool AuthorizationClient SecurityAI Coding IDE
6 applicable AIDEFEND defenses
Source: IDEsaster: A Novel Vulnerability Class in AI IDEs 
Author: Ari "MaccariTA" Marzouk
Original article: Dec 6, 2025

Threat Analysis

  • The vulnerable unit is the composed desktop application. The recurring chain is indirect prompt injection, an agent's ordinary or vulnerable tool, and an automatic base-IDE feature. Reviewing only the declared tool list misses authority inherited from schema loaders, workspace settings, and native integration.
  • A file write can become a network request. A compromised agent can place a secret in a remote $schema URL. Visual Studio Code, JetBrains, or Zed may fetch it automatically, including during diff preview, so approval displayed after parsing is already too late.
  • Settings can turn writes into code execution. The reported paths bound a writable executable through php.validate.executablePath or PATH_TO_GIT. A *.code-workspace change could also add an outside folder and restore access to the executable path.
  • The scope is broad, but remediation is product-specific. The author reported more than 30 findings, 24 CVEs, and at least one path in every tested application. This was controlled responsible-disclosure research, and there is currently no public evidence that IDEsaster has been used in actual attacks.

Applicable AIDEFEND Defenses (6)

AID-H-017.002
Least-Privilege Tool Architecture
Very High
Give the coding agent allowlisted, typed, single-purpose capabilities instead of broad filesystem, shell, HTTP, or native access. Separating ordinary source edits from sensitive settings, workspace-root changes, executable files, and OS integration removes the combination of powers that IDEsaster chains require.
AID-H-019.001
URL Normalization & Allowlist Filtering
Very High
Route every IDE background fetch, including schema loading during preview, through one safe-fetch service that canonicalizes the URL, resolves and pins the destination, checks redirects and private ranges, and allows only approved hosts. Placement is decisive: filtering only the agent's HTTP tool leaves the base IDE's schema request untouched.
AID-H-018.001
Tool Parameter Constraint & Schema Validation
High
Define a strict file-operation schema that rejects unknown fields, path traversal, workspace escapes, and writes to high-risk targets such as .vscode, .idea, *.code-workspace, executable hooks, or equivalent product configuration. This blocks the specific write primitives before the IDE consumes them.
AID-H-018.003
High-Impact Independent Validation & Approval Gate
High
Before any write or preview side effect, independently present and approve the exact target, content digest, workspace change, executable binding, and expected network effect. Binding approval to the canonical action prevents a generic “approve file edit” dialog from authorizing a different setting or a fetch that already occurred.
AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
High
Inventory the exact IDE, coding assistant, extension, and embedded runtime versions in use; reconcile each product with its own advisories; stage fixed releases; and use endpoint readback to verify that vulnerable builds have exited. The 24 CVEs span different products and cannot be closed by citing one representative version.
AID-I-007
Client-Side AI Execution Isolation
Medium
For Electron or native desktop products, expose only named, allowlisted capabilities across the native bridge and reject arbitrary IPC, filesystem paths, Node globals, or generic native calls. This can separate the AI runtime from base-IDE and OS authority, but it applies only where the client architecture provides an enforceable bridge boundary.

What Defenders Should Do Now

  • Inventory every AI IDE and coding assistant version, then reconcile each product against the IDEsaster advisories. Do not assume one vendor's update closes the same primitive in another IDE.
  • Test the composed application, not only the agent tool list: write remote-schema JSON, modify IDE settings, change multi-root workspace files, and observe whether preview or parsing causes network or execution side effects before approval.
  • Remove agent write access to IDE settings, workspace descriptors, executable hooks, and paths outside the approved project unless an exact action receives independent approval.
  • Route schema loaders and every other background fetch through a centrally enforced safe-fetch boundary. Log the initiating file, feature, final URL, redirect chain, and decision.
  • For desktop clients, minimize the native bridge and run agent-controlled code in an isolated workspace without host credentials or unrestricted egress. Treat warnings as support for, not substitutes for, enforceable boundaries.

Conclusion

IDEsaster is an authority-composition problem. A modest file-write tool becomes dangerous when the surrounding IDE silently contributes network access, workspace expansion, executable configuration, and native privileges. AIDEFEND  maps this attack path to controls at each real boundary: narrow tools, strict paths, pre-effect approval, IDE-wide safe fetch, client isolation, and verified version remediation. The review target must be the full agent-plus-IDE system, including what happens during preview.