Claude Code RCE — Config Files Are the New Attack Surface

Check Point Research published a disclosure on February 26 detailing two vulnerabilities in Anthropic’s Claude Code that, together, let an attacker achieve remote code execution and silently drain API keys — triggered by nothing more than a developer cloning a repo and opening the tool. Both CVEs are fully patched. But reading the technical breakdown made something clear to me: these aren’t edge-case bugs in one product. They’re a preview of how every agentic coding tool will be attacked going forward.

TL;DR

• CVE-2025-59536 (CVSS 8.7): Hooks in .claude/settings.json ran arbitrary shell commands before the trust dialog appeared — clone and open was sufficient for RCE. Patched in version 1.0.111.
• CVE-2026-21852 (CVSS 5.3): ANTHROPIC_BASE_URL set in a project config silently redirected all API traffic to an attacker-controlled server, leaking the active API key before any warning. Patched in version 2.0.65.
• Not just an Anthropic problem: MCP configs, hook runners, and environment variable injection exist across Cursor, Cline, and every MCP-enabled agent — they all share this threat model.
• Action required: Verify you’re running ≥ 2.0.65, audit every .claude/settings.json and .mcp.json in your repos, and rotate API keys if you ran Claude Code against untrusted repos between mid-2025 and January 2026.

What Check Point Found

The disclosure covers two separate vulnerabilities with a combined attack surface that is more serious than either CVE in isolation.

CVE-2025-59536 targets the Hooks system in Claude Code. Hooks are shell commands defined in .claude/settings.json that Claude Code executes automatically at defined lifecycle points — session start, file change, tool call completion. The vulnerability: those hooks ran before the trust dialog appeared. An attacker who plants a malicious .claude/settings.json in a public repo gets code execution the moment a developer opens that repo in Claude Code. No confirmation prompt. No warning. One clone, full shell access.

Check Point’s disclosure timeline shows this was reported to Anthropic on July 21, 2025, with a final fix on August 26, 2025, and the CVE formally published on October 3, 2025. Patch version: 1.0.111.

CVE-2026-21852 is quieter but arguably more dangerous for teams. Claude Code respects an ANTHROPIC_BASE_URL environment variable that overrides where API requests go. The vulnerability: this value could be set in a project-level config file and took effect before Claude Code showed any trust prompt. An attacker sets ANTHROPIC_BASE_URL to their own server, the developer clones and opens the repo, and every API call — including the authentication headers — goes to the attacker before the user sees a single warning. The API key arrives at an attacker-controlled endpoint silently.

This was reported on September 3, 2025, fixed on December 28, 2025, and published as a CVE on January 21, 2026. Patch version: 2.0.65.

If your team pins Claude Code versions, you may still be running a version that is exposed to one or both of these vulnerabilities. The minimum safe version is 2.0.65. Teams running anything below 1.0.111 are exposed to both.

Why This Matters

The immediate remediation is straightforward — update the tool, rotate keys, audit configs. But that’s the surface. The more important reading of this disclosure is architectural.

I’ve been treating .claude/settings.json as infrastructure for months, but most teams treat it as metadata — something that lives in the repo, gets committed, and configures “agent behavior” in an abstract sense. Check Point just demonstrated with a working reverse shell that it is execution infrastructure. The distinction matters because it changes how you handle it: you don’t commit execution infrastructure without review, you don’t clone repos containing it without inspection, and you definitely don’t let it run before a trust boundary is enforced.

The same analysis applies to every equivalent config in this class of tool:

• .mcp.json — MCP server definitions that tell the agent which servers to connect to and with what permissions
• Cursor’s .cursor/ directory — rules and tool configurations that shape how the assistant behaves in context
• Cline’s hook configurations — similar lifecycle-triggered execution points
• Aider’s config — controls what the agent sees and acts on

None of these are unique to Anthropic. Every agentic tool that reads repository configuration and executes something based on it has a version of this threat model. The specific implementation differs; the exposure class does not.

The enterprise blast radius compounds this. In Anthropic Workspaces, a single compromised API key isn’t just a billing problem — it’s an access problem. Workspaces associates files and project data with the workspace itself, not individual keys. One developer runs Claude Code against a poisoned repo in a shared dev environment; one key gets exfiltrated; every project file shared across that workspace is now reachable by the attacker. For a team of 20 sharing a workspace, that’s one clone away from total exposure.

Anthropic Workspaces multiplies the blast radius of CVE-2026-21852 significantly. A stolen API key in a Workspace context isn’t just a cost exposure — it’s a file access exposure for every project shared in that workspace. If you share a Workspace across your dev team, treat any key rotation as mandatory, not optional.

Compare this to how the same class of attack has been handled historically. Supply chain attacks through package.json postinstall scripts have existed for years — they’re why tools like npm audit and socket.dev exist, and why enterprise policies often restrict lifecycle hooks in package managers. The same institutional response hasn’t happened yet for agent config files, partly because the tooling is newer and partly because the execution layer wasn’t obvious until now. Check Point made it obvious.

Treat every repository config file that an agentic tool reads — .claude/settings.json, .mcp.json, .cursor/, Cline configs — the same way you treat package.json scripts in an untrusted dependency: assume it can execute code, and review it before the tool runs.

The comparison to package.json postinstall hooks is instructive but incomplete. Those attacks required a dependency to be installed. These attacks require only that a developer opens a repo in their preferred coding tool — a workflow that happens dozens of times a day, often without thinking twice about what configuration files that repo contains.

The Take

These two CVEs aren’t primarily a story about Anthropic shipping buggy code. Anthropic received the disclosures responsibly, fixed both vulnerabilities within months, and published the CVEs before Check Point went public. The remediation process here was professional.

The story is that the config-as-execution-layer architecture now has documented, weaponized exploits in the wild. That changes the risk calculation for every team using agentic coding tools — not just Claude Code users.

My read: your team needs a written policy for trusting repo-level agent configs before this becomes your incident, not after. That policy doesn’t need to be complex. It needs to answer three questions: Who reviews .claude/settings.json and equivalent files before a repo is opened in an agent tool? What’s the rotation policy for API keys used with agent tools? Which repos are considered trusted environments for running agents with elevated hook permissions?

If you don’t have answers to those three questions, you have the same threat model that Check Point demonstrated against — just waiting for someone to plant the right config file in a repo your team will eventually clone.

Practical defense checklist:

• Verify Claude Code version ≥ 2.0.65 across your team
• Audit .claude/settings.json and .mcp.json in every repo before opening in an agent tool
• Treat ANTHROPIC_BASE_URL as a sensitive environment variable — it should never come from a repo config
• Rotate API keys for any developer who ran Claude Code against an untrusted repo between mid-2025 and January 2026
• Apply the same review process to equivalent configs in Cursor, Cline, and any MCP-enabled tool your team uses

The tools are not going to stop reading config files — that’s a core part of what makes them useful. But the industry assumption that config files are passive metadata is over. Config files that automate agent behavior are part of the execution layer. Start treating them that way.