Navigating security vulnerabilities in Claude Code for enterprise developers

Enterprise development teams are moving fast with agentic coding tools, and Claude Code is a prime example: it can read repos, run commands, and connect to external tools through MCP (Model Context Protocol). That power also creates a new reality: repository files are no longer passive configuration—some of them can trigger execution paths.

In February 2026, Check Point Research publicly disclosed three critical Claude Code weaknesses that can be triggered by opening a malicious repository, including remote code execution and API key exfiltration. (research.checkpoint.com)

This article breaks down what happened, how exploitation worked (hooks, MCP servers, and environment variables), what Anthropic patched, and how to integrate AI tooling more safely in enterprise pipelines.

What Check Point disclosed (and why it matters to enterprises)

The disclosed issues revolve around a single enterprise-grade risk pattern:

• A developer clones (or checks out) a repo.
• Claude Code reads repo-controlled configuration files.
• Sensitive actions occur before the user meaningfully confirms trust, or trust controls are bypassed through settings that are themselves repo-controlled. (research.checkpoint.com)

In practical terms, this is a supply-chain-style problem: the “payload” can live in ordinary-looking project files that pass through PRs, internal mirrors, forks, or demo repositories.

The three flaws at a glance

Exploitation path: Hooks as a repo-delivered execution mechanism

Claude Code supports “hooks” that can execute arbitrary shell commands automatically. Anthropic’s documentation is explicit that hooks are powerful and risky. (docs.anthropic.com)

The core enterprise lesson is not “hooks are bad,” but: if hooks (or hook-related settings) can be influenced by repository-controlled files, then a repo can become a delivery mechanism for execution.

What this looks like in real workflows

Typical developer behavior makes this exploitable:

1. A developer clones a repository for a fix, review, or build.
2. They start claude inside that directory.
3. Claude Code reads project configuration and initializes features (including automation features meant for productivity).
4. The attacker’s embedded configuration drives unintended behavior.

Anthropic addressed a hooks-related weakness captured as GHSA-ph6w-f82w-28w6 by improving how the trust warning communicates execution implications, and by hardening the safety expectations around “proceeding” in an untrusted folder. (advisories.gitlab.com)

Exploitation path: MCP servers + consent bypass leading to RCE (CVE-2025-59536)

MCP lets Claude Code interact with external tools via “MCP servers,” and those servers can be defined in .mcp.json. In the Check Point proof of concept, simply initializing an MCP server could run a local command (demonstrated by launching Calculator) and was later escalated to a reverse shell. (research.checkpoint.com)

The key issue in CVE-2025-59536 was not just that MCP servers can execute commands—teams may accept that by design. The issue was that a malicious repo could bypass or undermine user consent by setting auto-approval options in a repo-controlled settings file, causing execution to occur before the trust dialog could protect the user. (research.checkpoint.com)

Why this is especially dangerous in enterprises

MCP is attractive to teams because it standardizes integrations and supports consistent tooling across a group. Check Point noted settings that enable MCP servers automatically for collaboration—exactly the kind of “make it seamless for teams” setting that becomes high-risk when repo-controlled. (research.checkpoint.com)

Exploitation path: API key theft via ANTHROPIC_BASE_URL override (CVE-2026-21852)

CVE-2026-21852 is an information disclosure bug: a malicious repo could define environment variables in a project settings file and override ANTHROPIC_BASE_URL so the tool sends API traffic to an attacker-controlled endpoint—potentially leaking API keys—before trust was confirmed. (nvd.nist.gov)

This is the “quiet” class of failure that enterprises often miss, because nothing obviously “runs” on the endpoint like a shell does—credentials simply leave the workstation.

If your organization uses shared workspaces or centralized AI-dev resources, leaked keys can expand the blast radius beyond a single developer machine, depending on what those keys can access.

What Anthropic patched (and what you should verify)

From the public record:

• CVE-2025-59536: fixed in Claude Code 1.0.111. (nvd.nist.gov)
• CVE-2026-21852: fixed in Claude Code 2.0.65. (nvd.nist.gov)
• GHSA-ph6w-f82w-28w6: fixed in 1.0.87 by improving the startup warning / trust messaging and expectations. (advisories.gitlab.com)

Also note: Claude Code (and its ecosystem) has had other security-relevant findings related to MCP/IDE connectivity in the broader timeframe, reinforcing that “local integration surfaces” deserve the same scrutiny as cloud services. (securitylabs.datadoghq.com)

Secure AI tool integration: a practical enterprise playbook

The goal isn’t to ban agentic tooling—it’s to make its trust boundaries explicit and enforceable.

Treat AI tool config as code execution surface

Add these files/patterns to mandatory review and automated scanning (pre-merge and pre-checkout where possible):

• .claude/settings.json
• .mcp.json
• Any repo documentation instructing developers to “enable all MCP servers” or “auto-approve tools”
• Any settings that define environment variables (especially endpoint overrides)

If you already have “dangerous file” policies for CI (like restricting changes to build scripts), extend them to AI agent configuration.

Enforce version governance (especially for manual-update environments)

• Maintain an approved Claude Code version baseline and update cadence.
• Fail builds or developer environment bootstrap if the binary/package is below your secure minimum.
• For contractors and BYOD, consider a managed dev container or virtual workspace that standardizes versions.

NVD explicitly calls out the vulnerable “prior to” versions for both CVEs—use that as a concrete compliance line. (nvd.nist.gov)

Apply least privilege to AI credentials

• Prefer short-lived, scoped API keys where possible.
• Separate keys by environment (dev vs staging vs prod).
• Add budget/rate-limit guardrails to reduce cost impact if a key leaks.
• Store secrets in an enterprise secrets manager; avoid long-lived keys in developer dotfiles.

Control egress and endpoint integrity

Because CVE-2026-21852 involves redirecting API traffic, you should assume “endpoint override” is a class of risk:

• Use DNS/egress controls to restrict outbound traffic to known vendor endpoints.
• Alert on developer tools making TLS connections to newly seen domains immediately after repo open.
• Consider certificate pinning policies where feasible (balanced against operational complexity).

Sandboxing: assume “repo open” can be a trigger

For high-assurance teams:

• Run agentic tools inside dev containers or ephemeral VMs.
• Use separate OS user profiles for experimental repos.
• Disable shell execution features unless explicitly needed for the task.

Add “AI-aware” detection and response to your SOC

From a SOC perspective, exploitation may look like:

• A developer opens a repo, then a new process spawns quickly (bash, sh, powershell, cmd, python, etc.).
• Unusual child processes from the Claude Code process tree.
• Sudden outbound connections to untrusted infrastructure after tool startup.

A secure-by-default checklist for enterprise developers

1. Update Claude Code to patched versions (verify installed versions, don’t assume). (nvd.nist.gov)
2. Block or tightly govern repo-controlled automation (.mcp.json, .claude/settings.json) with review + scanning. (research.checkpoint.com)
3. Disallow untrusted endpoint overrides and monitor for suspicious ANTHROPIC_BASE_URL-style patterns. (nvd.nist.gov)
4. Run risky repos in containers/VMs; reserve host execution for trusted codebases.
5. Instrument SOC detections for process spawn + outbound connection anomalies tied to AI tools.

Closing thought: make “trust” enforceable, not just a dialog

The common theme across these issues is that “trust” can’t be a UI moment—it must be an enforceable boundary that prevents execution and sensitive network activity until it’s explicitly and reliably established.

Agentic development tools will keep evolving. The enterprises that win will be the ones that pair productivity with guardrails: policy-driven configuration controls, strong egress governance, least-privilege credentials, and SOC workflows that can keep up with developer velocity