The pattern-based approach for Bash is fundamentally limited

[Kotivskyi]

Summary

Security testing revealed that the current pattern-based approach for the Bash hook can be bypassed through various path obfuscation techniques. Additionally, the Grep tool has no hook at all, allowing unrestricted file reads.

Bypasses Found

1. Grep Tool - No Hook (Critical)

The Grep tool is not protected by any hook, allowing full file content extraction:

# Reads entire SSH private key
grep ".*" /path/to/.ssh/id_rsa

Impact: Can read ANY file on the system, including credentials, private keys, and secrets.

---

2. Base64 Encoded Path (Bash Bypass)

Encoding the path in base64 evades pattern matching:

F=$(echo "BASE64_ENCODED_PATH" | base64 -d) && cat "$F"

Why it works: The protected path pattern never appears in the command string.

---

3. find -exec (Bash Bypass)

Using find to locate files by name, then execute commands:

find /Users/username -name "id_rsa" -exec cat {} \;

Why it works: The protected path is not in the command; only the filename is searched.

---

4. String Concatenation (Bash Bypass)

Breaking the path into concatenated strings:

eval "cat /Users/user/.s""sh/id_rsa"

Why it works: The path pattern is split across strings and only assembled at runtime.

---

Root Cause Analysis

The fundamental limitation is that regex pattern matching on command strings cannot catch:

1. Encoded paths - Base64, hex, URL encoding
2. Runtime-constructed paths - Variables, command substitution
3. Indirect access - find, locate, xargs with dynamic input
4. String obfuscation - Concatenation, escape sequences

Environment

• macOS (case-insensitive filesystem)
• Claude Code with damage-control hooks
• Python-based PreToolUse hooks

[Kotivskyi]