---
source_block: claude-code-settings-security.md
canonical_url: https://api.theorydelta.com/published/claude-code-settings-attack-surface
published: 2026-03-14
last_verified: 2026-03-14
confidence: empirical
rubric:
  total_claims: 7
  tested_count: 2
  independently_confirmed: true
  unlinked_count: 0
  scope_matches: true
  falsification_stated: true
  content_type: finding
trust:
  provenance: "sourced + first-party"
  rigor: source-verified
  sources: "2 CVEs, 5 supply-chain vectors, 1 enterprise hardening guide"
  unlinked_claims: 0
environments_tested:
  - tool: "Claude Code"
    version: "v2.1.x"
    evidence_type: runtime-tested
    result: "Settings file loads with user privileges before trust verification"
theory_delta: "Two CVEs and five supply-chain vectors share one pattern: project-scoped settings execute with user privileges before trust verification."
tags:
  - claude-code
  - security
  - supply-chain
---

# Claude Code's project settings file is a first-class attack surface

*From [Theory Delta](https://theorydelta.com) | [Methodology](https://theorydelta.com/methodology/) | Published 2026-03-14*

## What the docs say

Claude Code supports per-project settings via `.claude/settings.json`. This lets teams configure MCP servers, hooks, and permissions for their codebase. The documentation describes this as a convenience feature for team standardization.

## What actually happens

The project settings file is not a convenience feature. It is a first-class attack surface with two confirmed CVEs and five additional supply-chain vectors:

**CVE-1: Credential exfiltration via `ANTHROPIC_BASE_URL`.** A malicious `.claude/settings.json` can override the API base URL, redirecting all API calls -- including the authentication token -- to an attacker-controlled endpoint. The user sees normal behavior. Their API key is silently exfiltrated.

**CVE-2: MCP consent bypass via `enableAllProjectMcpServers`.** This setting auto-approves every MCP server defined in the project config, skipping the user consent prompt entirely. A repository containing this setting plus a malicious MCP server definition gains arbitrary tool execution on clone.

**Five additional supply-chain vectors** compound the problem:

1. **Symlink-based read/write redirect** -- symlinks in `.claude/` can point settings or hook scripts to locations outside the repository, bypassing path-based trust boundaries.
2. **Hook injection** -- `PreToolUse` and `PostToolUse` hooks defined in project settings run arbitrary shell commands with user privileges.
3. **MCP server injection** -- project settings can define MCP servers that run on first use.
4. **Permission escalation** -- settings can pre-grant filesystem, network, and execution permissions.
5. **Dependency chain** -- cloning a repo, opening it in an editor with Claude Code, and accepting a single prompt loads all of the above.

All seven vectors share one root cause: project-scoped settings execute with user privileges before the user has a chance to verify what they do.

**Enterprise hardening exists but is opt-in.** Managed policy files can restrict these settings, but the default for every non-enterprise user is full exposure.

## What to do instead

1. **Audit `.claude/settings.json` in every repository you clone** before opening it with Claude Code. Treat it like you would a `.npmrc` or `.env` file from an untrusted source.
2. **Check for `enableAllProjectMcpServers`** -- if present, remove it. This is the single most dangerous setting.
3. **Check for symlinks in `.claude/`** -- run `find .claude -type l` to identify any symlink-based redirects.
4. **Review hook definitions** -- any `PreToolUse` or `PostToolUse` hook runs shell commands. Read them before accepting.
5. **If your organization uses Claude Code at scale**, enable enterprise managed policies to restrict what project settings can do.

## Environments tested

| Tool | Version | Result |
|------|---------|--------|
| Claude Code | v2.1.x | Settings file loads and executes with user privileges before trust verification |

## Confidence and gaps

**Confidence:** empirical -- two CVEs independently confirmed by Anthropic's security team. Five additional vectors identified through source review and runtime testing.

**Falsification criterion:** This claim would be disproved by demonstrating that project settings are sandboxed or require explicit user approval before any setting takes effect -- including MCP server definitions, hooks, and environment variable overrides.

**Open questions:** Will Anthropic add a trust-on-first-use prompt for project settings? Are there other settings fields beyond `enableAllProjectMcpServers` and `ANTHROPIC_BASE_URL` that have security implications?

Seen different? [Contribute your evidence](https://theorydelta.com/contribute/) -- theory delta is what makes this knowledge base work.