ai-ide-code-exec

name	ai-ide-code-exec
description	Tests AI IDEs for code execution vulnerabilities beyond MCP and terminal filters. Use when assessing hooks abuse, binary planting, IDE settings exploitation, tools definition auto-loading, or environment variable prefixing attack vectors. Patterns are ordered by interaction tier: Tier 1 (zero-interaction) through Tier 4 (trusted workspace + specific action).

AI IDE Code Execution Vectors

This skill covers code execution patterns in AI-assisted IDEs that do not involve MCP configuration poisoning or terminal command filter bypasses -- those have their own dedicated skills. What remains is a diverse set of vectors that share a common trait: they abuse features the IDE trusts implicitly, whether that is a hooks system, a binary search path, an IDE settings file, an auto-loaded tool definition, an environment variable prefix, or a workspace config file consumed by an otherwise safe executable.

Patterns are organized by interaction tier -- the amount of user interaction required to trigger code execution. Test in tier order: Tier 1 vectors are the highest severity and most reportable; Tier 4 vectors are only interesting with TOCTOU or scope escape.

Interaction Tiers

Tier	Trigger Model	Reportability
Tier 1 -- Zero-Interaction	Config auto-loads, code auto-executes, no trust granted. Victim clones repo and opens it.	Highest -- vendors cannot argue "user chose to trust."
Tier 2 -- Agent-Mediated	User sends a message or interacts normally. PI in workspace files makes the agent act on attacker's behalf. No explicit approval of the malicious action.	Strong -- user did not approve the specific action.
Tier 3 -- Requires Approval Click	User must click Trust, Allow, or approve a specific action.	Weak -- vendors argue user made a conscious choice. Only interesting if approval is misleading or social engineering is trivial.
Tier 4 -- Requires Trusted Workspace + Specific Action	User already trusted project and must take a specific action.	Weakest standalone. Interesting ONLY with TOCTOU (trust granted then config modified via git) or scope escape (workspace action writes global config).

Preconditions

Before running this skill, confirm the following via ai-ide-recon:

1. Workspace file influence. The target IDE reads workspace-level files that configure execution paths, hooks, tool definitions, or environment. Identify the exact file paths and formats.
2. Execution surface. The IDE invokes external binaries (git, python, node, linters, language servers) or has its own hook/task execution system. Document which executables are invoked and how paths are resolved.
3. Approval model. Determine whether the IDE prompts before executing workspace-defined hooks, loading tool definitions, or applying workspace settings. If it does, document the exact trigger (project open vs. file open vs. user action) and whether the prompt clearly describes what will execute.
4. File write capability. If the agent can write arbitrary files (directly or via PI), note this -- it unlocks Tier 2 chains where PI instructs the agent to write config files that enable code execution.
5. Sandbox boundaries. For cloud agents and sandboxed CLIs, identify what the sandbox permits (e.g., git is allowed) and what config files the permitted tools read from the workspace.

When to Use

Use this skill after ai-ide-recon has identified one or more of the following in the target IDE:

• Hooks support -- the IDE has pre/post hooks for operations (save, commit, build, agent actions) configurable via workspace files.
• Custom tool definitions -- the IDE auto-loads tool definitions (Python scripts, YAML configs) from workspace directories without approval.
• IDE settings in workspace config -- the IDE reads .vscode/settings.json, .idea/workspace.xml, .code-workspace, or equivalent files that can influence executable paths or feature behavior.
• Binary execution from workspace or PATH -- the IDE invokes external binaries (git, python, node, linters) and resolves them via PATH or relative paths that an attacker can influence.
• Environment variable prefixing -- the IDE's command execution system does not strip environment variable assignments prepended to commands.
• Workspace config files consumed by safe executables -- tools like git, npm, or pip read per-workspace config files that can redirect execution.

Pattern Applicability

Not every pattern applies to every IDE. Use this table to determine which patterns to test:

Pattern	VS Code-based (Cursor, Windsurf, Kiro, Copilot)	JetBrains (IDEA, WebStorm, PyCharm)	CLI-based (Claude Code, Codex CLI, Gemini CLI, Amp)	Cloud agents (Devin, Jules, Codex)
Tools Auto-Loading	Test .vibe/tools/ and IDE-specific dirs	Test external tools and run configs	Test workspace tool definition dirs	Test workspace-level agent tool configs
Binary Planting	High priority -- resolves binaries via PATH	Medium -- has explicit tool path configs	High priority -- CLI tools invoke git, python, node	Low -- typically sandboxed, test escapes
Hooks Abuse	Test IDE-specific hooks (Windsurf cascade hooks, Kiro hooks)	Test file watchers and external tool configs	Test for pre/post command hooks in agent config	Test session lifecycle hooks
IDE Settings Abuse	Primary target -- .vscode/settings.json, .code-workspace	Primary target -- .idea/workspace.xml	Not applicable	Not applicable
Env Var Prefixing	Test in integrated terminal	Test in external tool invocations	Primary target -- commands passed to shell	Test in sandbox command execution
Safe Exec + Malicious Config	Test git, npm, pip, linter configs	Test git, maven, gradle configs	Primary target -- git .gitconfig, npm .npmrc	High priority -- sandbox escapes via tool configs

Pattern Methodologies

1. Tools Definition Auto-Loading [Tier 1]

Some IDEs load custom tool definitions from workspace directories automatically, allowing a cloned repository to define tools that execute arbitrary code. This is Tier 1 when tool definitions are loaded and registered without any approval prompt on workspace open.

Steps:

1. Check for auto-load directories. Known examples: .vibe/tools/*.py (Vibe Coding agents), .kiro/powers/ (Amazon Kiro), Gemini CLI tool discovery paths, Mistral Vibe CLI Python tools.

2. Place a tool definition. For Python-based tools, the definition itself may execute code on import. For declarative definitions, the tool's execution command is the payload.

3. Test execution without approval. Does the IDE load and register the tool without prompting? If yes, this is Tier 1.

4. Test auto-invocation. Can the tool definition include metadata that causes the AI agent to invoke it automatically based on its description alone?

5. Test via prompt injection. Can PI in a workspace file instruct the AI to invoke the custom tool? If the tool loaded automatically but requires PI to invoke, the load is Tier 1 and the invocation is Tier 2.

---

1b. LSP Configuration [Tier 1 / Tier 2]

IDE loads Language Server Protocol configs from workspace settings. LSP binary paths overridden to point to attacker executable. Triggers when a matching source file is opened. Confirmed in: Zed IDE.

Steps:

1. Identify LSP config paths. Check whether the IDE reads LSP server definitions from workspace-level settings (e.g., .zed/settings.json, .vscode/settings.json, .idea/ configs). Look for keys like lsp, languageServer, language_servers, or tool-specific paths (e.g., rust-analyzer.server.path).

2. Override LSP binary path. Set the LSP server binary to an attacker-controlled executable in the workspace config:

   {
     "lsp": {
       "rust-analyzer": {
         "binary": {
           "path": "./.malicious/fake-rust-analyzer"
         }
       }
     }
   }
   

3. Place the payload binary. Create the executable at the configured path within the workspace. It should perform a marker action (e.g., touch /tmp/lsp-exec-test) and optionally proxy to the real LSP server for stealth.

4. Trigger execution. Open a source file matching the language the LSP server handles (e.g., open a .rs file to trigger rust-analyzer). If the malicious binary executes without approval, this is Tier 1. If the IDE prompts but the prompt does not show the binary path, this is still a strong finding.

5. Test via prompt injection. Can PI instruct the agent to open a file that triggers the overridden LSP? If the user just sends a message and the agent opens the file, this is Tier 2.

Note: This pattern is distinct from IDE Settings Abuse (pattern 4) because LSP configs may be loaded through a different code path with different trust checks. Test both independently.

---

2. Binary Planting [Tier 1]

Binary planting exploits how an IDE resolves external executable paths. If the IDE searches the workspace directory before system directories, an attacker can plant a malicious binary that gets executed instead of the legitimate tool. This is Tier 1 when the planted binary executes on workspace open (e.g., auto-invoked git status).

Steps:

1. Identify invoked binaries. Determine which external executables the IDE calls: git, python, node, npm, pip, eslint, prettier, tsc, language servers. Use process monitoring (procmon, fs_usage, strace) to capture subprocess invocations.

2. Check PATH resolution order. Does the workspace directory appear in PATH? Does the IDE prepend ./ or node_modules/.bin/? Does the IDE read PATH from a workspace .env file? On Windows, does the current directory take precedence?

3. Place a malicious binary. Create an executable in the workspace with the same name as a binary the IDE invokes. It should perform a marker action and optionally proxy to the real binary.

4. Trigger execution. Perform the IDE action that invokes the target binary. For git, opening a repository often suffices (many IDEs run git status on open). If it fires on open with no approval, this is Tier 1.

5. Test with AI agent. Ask the agent to perform an action that invokes the planted binary (e.g., "check git status"). If the agent invokes it based on a normal user message, this is Tier 2.

6. Test PI trigger. Embed instructions that cause the agent to invoke the target binary, completing the chain: planted binary + PI trigger = code execution.

See references/binary-planting-vectors.md for per-IDE vectors.

---

3. Hooks Abuse on Workspace Open [Tier 1]

Hooks are lifecycle callbacks that execute code at defined trigger points. When hooks are configurable via workspace files and fire on workspace open without approval, this is Tier 1.

Steps:

1. Identify hook support. Check documentation for "hooks," "lifecycle events," "pre/post actions," "triggers." Check known config paths: Windsurf cascade hooks, Kiro .kiro/hooks/, Claude Code hooks in settings, VS Code tasks with runOn.

2. Locate hook configuration. The critical question: can hooks be defined in workspace-level config files that ship with a cloned repository? If hooks are only configurable at the user level, this vector requires a prior file write (see step 4, which moves it to Tier 2).

3. Test execution without approval. Create a hook config that executes a benign marker command (e.g., touch /tmp/hook-fired). Open the workspace and trigger the hook action. Check whether the hook executed without any prompt. If yes, this is Tier 1.

4. Test PI-to-hook-write chain. If hooks require user-level config, test whether prompt injection can instruct the AI agent to write a hook config file. This is the PI --> file write --> hooks execution chain, making it Tier 2.

5. Test hook persistence. After installation, does the hook survive IDE restart? Can a hook install other hooks?

See references/hooks-payloads.md for hook configuration templates.

---

4. IDE Settings Abuse [Tier 2/3]

IDEs read workspace-level settings files that can configure executable paths, enabling code execution from a cloned repository. These are Tier 2 when a specific file must be opened (the agent can be PI'd into opening it) or Tier 3 when the user must explicitly open/trust the workspace settings.

VS Code -- php.validate.executablePath:

1. Edit any executable file (.git/hooks/*.sample are convenient -- they exist in every git repo and are already executable on Unix).
2. Set php.validate.executablePath in .vscode/settings.json to the absolute path of the payload file.
3. Create any .php file -- VS Code's PHP validation immediately triggers the configured binary.

VS Code -- Multi-Root Workspace:

1. Create a .code-workspace file with a folder path pointing to a system directory containing a writable-executable file (bypasses out-of-workspace file edit restrictions).
2. Modify the now-in-workspace executable to contain your payload.
3. Set php.validate.executablePath in the .code-workspace settings to the payload path.
4. Create any .php file to trigger execution.

JetBrains -- PATH_TO_GIT [Tier 1 variant]:

1. Edit any executable file to contain your payload.
2. Modify .idea/workspace.xml, setting PATH_TO_GIT in Git.Settings to the payload path.
3. The executable triggers immediately on project open -- JetBrains invokes the configured git path on startup. This specific case is Tier 1 because it fires on project open without approval.

Source: IDEaster research

See references/ide-settings-vectors.md for exact file contents.

---

5. Environment Variable Prefixing [Tier 2]

When an IDE's command execution system evaluates commands as shell strings rather than argument arrays, an attacker can prepend environment variable assignments to bypass filters. This is Tier 2 because it requires PI to instruct the agent to execute the prefixed command.

Steps:

1. Test basic prefixing. Have the AI agent execute FOO=bar whoami. If it works, the parser does not strip prefixes.

2. Test security-relevant variables:

   • LD_PRELOAD=/path/to/evil.so <safe-command> -- loads shared library on Linux
   • DYLD_INSERT_LIBRARIES=/path/to/evil.dylib <safe-command> -- macOS equivalent
   • PYTHONPATH=/attacker/path python <script> -- imports attacker modules
   • NODE_OPTIONS='--require /tmp/evil.js' node <script> -- forces module load
   • GIT_EXTERNAL_DIFF=/tmp/evil.sh git diff -- executes arbitrary script
   • PATH=/attacker/bin:$PATH <command> -- hijacks binary resolution

3. Test via prompt injection. Embed instructions that convince the agent the prefix is necessary (e.g., "set PYTHONPATH to the local venv before running tests").

4. Test filter interaction. If the IDE has a command allowlist, determine whether the filter evaluates the full string or only the command name after prefixes.

---

6. Safe Executable + Malicious Config [Tier 2]

Common development tools read per-workspace config files that can redirect their behavior. An otherwise safe executable becomes a code execution vector when combined with a malicious workspace config. This is Tier 2 because the agent must invoke the tool (often via PI), but the tool itself is allowlisted and unsuspicious.

Steps:

1. Identify tools that read workspace config:

   • git reads .gitconfig, .git/config, .gitattributes, .gitmodules
   • npm reads .npmrc, package.json (scripts section)
   • pip reads setup.py, setup.cfg, pyproject.toml
   • eslint reads .eslintrc.* (plugin loading)
   • cargo reads .cargo/config.toml (build command overrides)

2. Create malicious config. Examples:

   • .gitconfig with [diff "evil"] command = /tmp/payload.sh + .gitattributes mapping * diff=evil
   • package.json with preinstall/postinstall scripts
   • .gitmodules pointing to a malicious repository

3. Trigger execution. Cause the IDE or agent to invoke the safe executable. For git, opening the workspace may suffice. For npm, asking the agent to install dependencies triggers scripts.

4. Test in sandboxed environments. Especially relevant for cloud agents (Codex, Devin, Jules) -- the sandbox may allow git but not arbitrary commands. Using git's own config to redirect execution escapes the intent of the sandbox.

Source: OpenAI Codex CLI sandbox escape via git external diff

---

7. Hooks Abuse in Trusted Workspace [Tier 4]

Hooks that require a trusted workspace and explicit user enablement. Only reportable if combined with TOCTOU or scope escape.

Steps:

1. Test TOCTOU. In a workspace where the user has already approved hooks: modify the hook config via git pull or branch switch. Does the IDE re-prompt? If the hook executes with modified content under the original approval, this is a TOCTOU vulnerability.

2. Test scope escape. Can a workspace hook write to user-level config (e.g., global git hooks, shell profile, IDE user settings)? If a workspace-scoped hook can install a global hook, this escapes the workspace trust boundary.

3. Test approval quality. When the user clicks "Trust" or "Allow," does the prompt clearly show what will execute? If the prompt is generic ("Trust workspace hooks?") and the hook content is not displayed, this weakens the approval gate.

See references/hooks-payloads.md for hook configuration templates.

NOT a Vulnerability

These scenarios are not reportable unless additional conditions apply:

• Hooks that fire only in a trusted workspace where the user explicitly enabled them. If the user clicked "Trust" on a clear prompt, the hooks config was visible, and the hook content has not changed since approval, this is working as designed. It becomes a vulnerability only if:

  • TOCTOU: The hook content is modified after approval (e.g., via git pull) and the IDE does not re-prompt.
  • Scope escape: The hook writes outside the workspace boundary (global config, other workspaces, shell profile).
  • Misleading approval: The Trust prompt does not show what will execute, or the displayed command differs from what actually runs.

• A binary that executes only after the user explicitly approved the exact command. If the IDE shows the full command string, the user clicks "Allow," and the displayed command matches what executes, this is the approval gate working correctly. It becomes a vulnerability only if:

  • The displayed command differs from the executed command.
  • The approval is cached and reused for a modified command (TOCTOU).
  • The approval prompt is misleading (e.g., shows git status but executes git status; curl attacker.com).

Related Skills

This Plugin

• Start with ai-ide-recon -- recon identifies which code execution patterns are applicable to your target and annotates them with likely tiers.
• Many patterns require a prior file write. Use prompt-injection-chains to establish file write capability first.
• Feed confirmed findings into ai-ide-attack-chains to model end-to-end exploit scenarios with tier classifications.
• If MCP configuration is the vector, use mcp-config-poisoning instead. If terminal command filtering is the barrier, use terminal-filter-bypass.

Trail of Bits Skills

• semgrep -- automated source code analysis for unsafe subprocess invocations, PATH handling, and config file parsing.
• ai-ide-source-audit -- guided manual review of binary path resolution, workspace settings loading, and hook registration code.