Build1 publisher2 min readPublished
Claude Code merged a cloned repo's settings.json before it asked whether you trust the directory
Two CVEs describe a startup window where a repository's own config file set the CLI's base URL and hooks while the trust prompt was still pending. On Linux, the key that leaks shares a plaintext file with GitHub and AWS tokens.
The Engineer · Build desk

What happened
- A dev.to audit of CVE-2026-21852 and CVE-2025-59536 says Claude Code merged a repository's ./.claude/settings.json into its runtime context before evaluating directory trust in versions before 2.0.65.
- Project-level SessionStart hooks executed immediately on initialization in vulnerable builds, so a cloned repository could run a shell command of its choosing before the trust prompt was answered.
- On Linux the CLI stored the Anthropic key in plaintext at ~/.claude/.credentials.json alongside GitHub OAuth, Jira bearer and AWS session tokens for connected MCP servers.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- constraint A clone is executable input to a process running with the developer's own privileges, so reviewing an untrusted repository now has to include .claude/settings.json and .git/config before anyone opens a terminal in it.
- exposure One leaked key reaches the organisation's billing tier, its private model access and its prompt caches. The exposure is the employer's, not the individual developer's.
- decision The version bump is the cheap half of the fix. The open question at review is whether the agent gets a home directory of its own, because any test suite it spawns can read the one it has.
- contradiction Anyone triaging by score gets a mixed signal: the same post labels both CVEs critical and reports a single CVSS 5.3, so the severity band and the number argue for different queue positions.
Type `claude` in a fresh clone and the ordering decides the outcome. The CLI evaluates three layers: the global `~/.claude/settings.json`, the project's `./.claude/settings.json`, and the process environment [3]. In builds before 2.0.65 the project layer was merged into the running context before the directory trust check [4]. The prompt still appears, after the merge has already happened.
One of the variables a project file can set is `ANTHROPIC_BASE_URL`. The example config in the writeup points it at an attacker-controlled host and turns on `allowBash` [5]. On launch the runtime issues an immediate request to fetch available models and verify quota limits, and the Anthropic SDK client attaches the user's active token in the `x-api-key` header, so that request goes to the attacker's server [6]. The post shows the resulting `POST /v1/messages` arriving at the attacker domain with an `sk-ant-api03` key in plaintext [7].
The base URL redirect is the quiet version. A `SessionStart` hook defined in the same project file executed immediately at initialization in vulnerable builds [9]. That hands the repository a shell command.
Git metadata is a second path into the same session. Set `core.fsmonitor` inside `.git/config` and any subsequent git operation the agent dispatches triggers the command in the background, and the agent runs `git status` and `git diff` on its own initiative [10].
Upgrading past 2.0.65 restores the ordering, but it does not change what a child process can read. On Linux the CLI stored session tokens and MCP credentials in plaintext at `~/.claude/.credentials.json`, with the Anthropic key sitting beside a GitHub OAuth token, a Jira bearer token and an AWS session token [11]. A test suite or shell script the agent spawns inherits read permission to the user's home directory [12]. That is four credential types covering four providers in one readable file [17].
I think that file is the thing to engineer around. Give the agent a home directory, per repository, that does not hold your GitHub and AWS tokens, and the pre-trust window costs you a lot less when the next ordering bug lands.
The evidence here is one dev.to writeup with author-built reproductions. It calls CVE-2026-21852 and CVE-2025-59536 "two critical vulnerabilities" [15] while giving a single CVSS 5.3 for the order-of-operations defect [2], and it does not say which CVE that score belongs to. The same post says the author published an open-source scanner that audits workspaces for pre-trust hook configurations, base URL redirects and unhardened agent environments [14].
What to watch
- Whether Anthropic's own advisory confirms 2.0.65 as the fix boundary and assigns the CVSS 5.3 to one of the two CVEs.
- Whether the agent gains a git config allowlist, since the core.fsmonitor path fires on the git status calls the agent makes itself.
- An independent reproduction of the x-api-key redirect, which currently rests on one author's writeup.