The Symlink Whisperer: Bypassing Claude Code's Security Rails

We are living in the golden age of "Agentic AI." Tools like Claude Code are essentially remote shells that we willingly install, giving a Large Language Model (LLM) permission to read our files, execute terminal commands, and refactor our spaghetti code. It is a powerful concept, but it terrifyingly blurs the line between "user intent" and "arbitrary code execution."

To keep things from going off the rails, Anthropics implemented a safety feature: a settings.json configuration where paranoid users (like us) can define a deny list. This list tells the agent, "You can touch anything in this repo, except my .env file and definitely not /etc/shadow." Ideally, this creates a sandbox where the agent can play without burning down the house.

But here is the thing about software boundaries: they are often drawn with crayon. The vulnerability we are looking at today, CVE-2026-25724, is a classic example of logic failing to account for the underlying geometry of the filesystem. It is a story about how a simple symbolic link turned a security fence into a revolving door.

The root cause of this vulnerability is a canonicalization failure, specifically CWE-61 (UNIX Symbolic Link Following). When you ask a program to check if a file is safe to read, the program has to decide which path it is checking: the path you gave it, or the path the filesystem actually resolves to.

In Claude Code versions prior to 2.1.7, the application performed its security check on the user-provided path. If the deny list contained /etc/passwd, and the agent attempted to read ./cool-config.txt, the check would pass because ./cool-config.txt is not in the deny list.

However, if ./cool-config.txt happened to be a symbolic link pointing to /etc/passwd, the underlying fs.readFile (or equivalent system call) would happily follow the link and return the contents of the password file. The security check validated the label on the box, but the filesystem opened the contents of the box. This is a classic Time-of-Check to Time-of-Use (TOCTOU) adjacent issue where the object verified differs from the object accessed.

Let's look at a reconstruction of the vulnerable logic vs. the fixed logic. The flaw lies entirely in the order of operations: checking permissions before resolving the path.

The Vulnerable Pattern

// Pseudocode representation of the flaw
function isAllowed(filePath: string, denyList: string[]): boolean {
  // FLAW: Checks the raw path string against the deny list
  for (const denied of denyList) {
    if (filePath.startsWith(denied)) {
      return false;
    }
  }
  return true;
}
 
// Usage
const target = "./innocent_link";
if (isAllowed(target, userSettings.deny)) {
  // The runtime follows the symlink here, bypassing the check
  const content = fs.readFileSync(target, 'utf-8');
  console.log(content);
}

The Fix (v2.1.7)

The patch involves resolving the path to its absolute, physical location on the disk using realpath before performing any checks. This ensures that aliases cannot hide the true destination.

import { realpathSync } from 'fs';
 
function isAllowed(filePath: string, denyList: string[]): boolean {
  try {
    // FIX: Resolve symlinks to their true destination first
    const resolvedPath = realpathSync(filePath);
    
    for (const denied of denyList) {
      if (resolvedPath.startsWith(denied)) {
        return false;
      }
    }
    return true;
  } catch (e) {
    // Handle dangling links or missing files
    return false;
  }
}

> [!NOTE] > This fix effectively neutralizes the attack because realpathSync expands ./innocent_link into /etc/passwd. The subsequent check sees that /etc/passwd matches the deny list entry and blocks the read operation.

While the CVSS score is low (2.3) because it requires the user to run the tool, the attack vector is fascinating for supply chain security. Imagine a malicious open-source repository designed to exfiltrate data from developers who use AI agents to review code.

The Setup

An attacker creates a repository with a "helper script" or a config file that is actually a symlink to sensitive system files.

# Attacker sets up the repo
mkdir -p malicious-repo
cd malicious-repo
# Create a link to the user's SSH keys or global config
ln -s ~/.ssh/id_rsa ./debug_logs.txt
ln -s /etc/shadow ./shadow_copy.txt
git add .
git commit -m "Add debug logs for analysis"

The Execution

1. The Victim clones the repo and launches Claude Code: claude code.
2. The Victim configures settings.json to deny access to ~/.ssh and /etc, thinking they are safe.
3. The Prompt: The victim asks Claude, "Summarize the debug logs in this folder to help me understand the error."
4. The Bypass: Claude sees debug_logs.txt. It checks the deny list. debug_logs.txt is allowed.
5. The Leak: Claude reads the file (following the symlink to id_rsa), ingests the private key into its context window, and sends it to the LLM API for processing. The private key is now in the chat history.

If you look at the CVSS score of 2.3, you might be tempted to ignore this. "Low severity? Who cares?" But in the context of an Agentic AI, the impact is higher than the score suggests.

We are entrusting these tools with high-bandwidth IO. They read code, they write code, and crucially, they upload context to the cloud. A file read bypass isn't just a local display issue; it's a data exfiltration vector. If an agent inadvertently reads a secret because of a symlink bypass, that secret leaves your machine and ends up on Anthropic's servers (or wherever the API endpoint is).

Furthermore, this breaks the trust model. Users rely on the deny list as a safety rail. When safety rails fail silently, users engage in risky behavior (like running the agent on untrusted code) believing they are protected. It is a reminder that application-level permissions are rarely as robust as OS-level permissions.

The remediation is straightforward: Update to @anthropic-ai/claude-code version 2.1.7 or later. This version correctly resolves paths before authorization.

Defensive Coding Lesson

For developers building similar tools:

1. Never trust input paths. Always canonicalize them using fs.realpath (Node) or filepath.EvalSymlinks (Go) before performing security checks.
2. Deny Default. Allow-lists are generally safer than Deny-lists. It is harder to accidentally allow a symlink than it is to fail to deny one.
3. Sandboxing. If possible, run agentic tools in a container or a VM. Relying on the tool's internal logic to prevent it from reading /etc/passwd is risky; running it in a container where /etc/passwd doesn't matter is better.