Six AI Assistants, One Old Trick

You clone a repository. Your AI coding assistant reads the files to understand context. Within seconds, it's reading your SSH keys, environment variables, or internal documentation. No exploit kit required, just a symlink.

What Happened

Wiz Research tested six AI coding assistants for a vulnerability that's been around since the 1990s: symlink traversal. All six failed. Here's how the attack works: an attacker commits a symlink to a git repository pointing to a sensitive file outside the repo (like ~/.ssh/id_rsa). When you clone the repo and your AI assistant tries to read files for context, it follows the symlink and reads the target file. The assistant then includes that content in its context window, potentially sending your private keys or credentials to the LLM provider's API.

Git stores symlinks with file mode 120000, and the blob content is just the target path as plain text. Most developers don't realize symlinks work this way in git, or that they can be committed at all.

Timeline

This isn't a single incident. It's a class of vulnerability that keeps resurfacing:

• 1990s-2000s: Symlink attacks plague Unix systems. Race conditions in /tmp directories become a standard security checklist item.
• 2010s: Web application frameworks add symlink protections. The issue fades from engineers' minds.
• 2023-2024: AI coding assistants gain adoption. File reading becomes automated and context-hungry.
• 2025: Wiz Research tests Claude Code and five other AI assistants. All follow symlinks without validation.
• Today: Your team is likely using at least one AI coding tool. The vulnerability window is open.

Which Controls Failed

Three layers of defense should have caught this:

• Input validation at the AI tool level: None of the tested assistants validated that file paths stayed within repository boundaries before reading. This violates basic path traversal protections that web frameworks implemented 15 years ago.
• User consent for sensitive file access: The assistants read files outside the repository without explicit user permission. A proper implementation would flag any path containing .. or absolute paths and require confirmation.
• Sandboxing: AI assistants run with the same file system permissions as the user. No containerization, no chroot jail, no principle of least privilege.

What Standards Require

• OWASP ASVS v4.0.3, Requirement 12.5.1: "Verify that the application server only accepts the HTTP methods in use by the application/API, including pre-flight OPTIONS, and logs/alerts on any requests that are not valid for the application context." While this focuses on HTTP methods, the principle applies: validate all inputs against a whitelist. For file operations, that means validating paths stay within expected boundaries.
• OWASP Top 10 2021, A01:2021 - Broken Access Control: Path traversal is explicitly called out. The guidance states: "Deny by default. Validate server-side file and directory permissions." AI coding assistants are server-side components from a trust boundary perspective. They should validate before reading.
• NIST 800-53 Rev 5, Control AC-3 (Access Enforcement): "The information system enforces approved authorizations for logical access to information and system resources." An AI assistant reading ~/.ssh/id_rsa without explicit authorization violates this control.
• PCI DSS v4.0.1, Requirement 6.2.4: "Bespoke and custom software are developed securely." If you're building internal tools that integrate AI assistants, you're responsible for ensuring they don't introduce path traversal vulnerabilities. This includes how you invoke third-party AI APIs.

Lessons and Action Items

For your immediate workflow:

1. Audit which AI coding assistants your team uses. Check their documentation for symlink handling. If it's not documented, assume it's vulnerable.
2. Before cloning unfamiliar repositories, run git ls-tree -r HEAD --long | awk '$2 == "120000" {print $5}' to list all symlinks. Review them before letting any AI tool read the repo.
3. Configure your shell to display symlinks distinctly. In bash: alias ls='ls -F --color=auto'. Symlinks appear with an @ suffix.
4. Run AI coding assistants in containers with read-only mounts of your code directories. Don't give them access to your home directory.

For your security program:

5. Add "symlink validation" to your secure code review checklist. Any code that reads user-provided file paths must validate against traversal, including through symlinks. Use realpath() or equivalent to resolve symlinks before checking boundaries.
6. If you're evaluating AI coding tools, test them: create a repo with a symlink to /etc/passwd, clone it, and see if the tool reads it without warning. Disqualify tools that fail.
7. Update your developer workstation hardening guide. Sensitive files like SSH keys should have 600 permissions. While this doesn't prevent symlink attacks, it limits damage if an attacker gains your user context.
8. For any internal tools that programmatically read files based on user input, implement these checks in order: (a) Reject absolute paths, (b) Reject paths containing .., (c) Resolve symlinks with realpath(), (d) Verify the resolved path is within allowed boundaries, (e) Check file permissions before reading.

For vendor management:

9. Ask your AI tool vendors: "How do you handle symlinks in file operations? Do you validate paths before reading? Do you require user consent for files outside the working directory?" Document their responses for your vendor risk assessment.
10. If you're subject to PCI DSS, SOC 2, or ISO 27001, treating AI coding assistants as third-party software means they fall under your vendor review requirements. A symlink vulnerability is a control gap.

The symlink attack isn't new. What's new is the automation. Your AI assistant will happily read 50 files to build context. It won't notice that one of them is a symlink to your production database credentials. You need to notice first.