Title: Security Vulnerability: Bash Permission Bypass via Command Chaining

Labels: security, bug, critical

Body:

A critical security vulnerability exists in the Claude Code Bash permission system that allows for a complete bypass of tool permissions via shell command chaining. The system appears to use simple prefix matching for Bash() rules, which can be exploited using shell operators (&&, ;, |, etc.) to execute arbitrary, unauthorized commands.

This vulnerability directly contradicts the official security documentation, which explicitly states that such chaining is prevented. This creates a dangerous situation where users may believe they have security controls in place when none actually exist.

Steps to Reproduce

1. Configure Permissions: In a project directory, create a .claude/settings.json file with a permissive echo rule:

   {
     "permissions": {
       "allow": ["Bash(echo *)"]
     }
   }

2. Start Claude Code: Run claude in that directory.

3. Verify Allowed Command: Ask Claude to run an allowed command.

   Prompt: run the command echo "this is a test"

   • Result: The command runs without a permission prompt, as expected.

4. Verify Disallowed Command: Ask Claude to run a disallowed command.

   Prompt: run the command ls -l

   • Result: Claude prompts for permission, as expected. Deny it.

5. Execute Bypass Attack: Ask Claude to run a chained command that starts with the allowed prefix.

   Prompt: run the command echo "bypass" && ls -l

Expected Behavior

According to the official iam documentation, Claude Code should detect the shell operator and block the command, as the ls -l portion is not authorized. The documentation states:

"Claude Code is aware of shell operators (like &&) so a prefix match rule like Bash(safe-cmd:*) won't give it permission to run the command safe-cmd && other-cmd"

The entire command echo "bypass" && ls -l should be treated as a new, unauthorized command requiring a permission prompt.

Actual Behavior

The entire command string echo "bypass" && ls -l is executed without any permission prompt. Both the echo and the ls -l commands run successfully, completely bypassing the permission system.

Impact

This vulnerability renders the Bash permission system ineffective as a security control against malicious command execution. An attacker with the ability to influence Claude's prompts could leverage any permissive rule (even a seemingly harmless one like Bash(echo *) or Bash(git status *)) to achieve:

• Remote Code Execution (RCE): by chaining with curl ... | bash.
• Data Exfiltration: by chaining with tar and curl or nc.
• System Damage: by chaining with rm -rf.
• Credential Theft: by chaining commands that read sensitive files.

The misleading documentation exacerbates this risk by giving users a false sense of security.

Recommended Actions

1. Immediate: The documentation must be updated immediately to remove the false claim about shell operator awareness. This is a critical step to prevent users from relying on a broken security feature.
2. Short-term: Consider disabling wildcard support for Bash rules until a proper fix is in place.
3. Long-term: The permission check must be re-architected to use a proper shell Abstract Syntax Tree (AST) parser. The system should parse the entire command, identify every individual command within the string, and check permissions for each one before execution.

I have a comprehensive analysis with dozens of additional attack vectors (including subshells, command substitution, process substitution, and obfuscation techniques) that I will post as a follow-up comment.

Thank you for your attention to this critical security matter.