On 25 February 2026, Check Point Research published a disclosure that deserves more attention than it received.

Three vulnerabilities in Claude Code — Anthropic's AI-powered command-line coding assistant used by thousands of development teams, allowed remote code execution and theft of Anthropic API credentials. The CVSS scores ranged from 5.3 to 8.7. All three have been patched. The story, on the surface, looks like a routine disclosure cycle.

It is not routine. What these vulnerabilities reveal about the changing architecture of software development is something that patching will not fix, and that most organisations are not yet equipped to reason about.

This post explains what actually happened, why it will keep happening, and what a genuine architectural response looks like.

What the vulnerability actually was

To understand why this matters, you need to understand the mechanism, not just the outcome.

Claude Code is a command-line tool. It integrates with your development environment and can read code, run commands, interact with version control, and call external services.

To do this, it uses a set of configuration mechanisms:

→  Hooks — shell commands that run automatically at lifecycle events (before a message is sent, after a response is received)

→  MCP servers — Model Context Protocol integrations that allow Claude Code to connect to external tools and services

→  Environment variables — configuration values including credentials

These mechanisms are defined in configuration files that live inside a project repository:

.claude/settings.json  ← hooks and project configuration

.mcp.json              ← MCP server definitions

Here is the critical detail: these files are version-controlled. They exist in the repository. They travel with it when the repository is cloned.

Check Point's finding was that by inserting a malicious Hook into .claude/settings.json, an attacker could trigger arbitrary shell command execution the moment a developer opened the project, before any trust dialogue appeared on screen. No additional interaction required. The command runs silently, with the permissions of the developer's machine.

The second vulnerability used .mcp.json to auto-approve all MCP server connections, bypassing the explicit consent mechanism that is supposed to prevent untrusted integrations from connecting to external services. The third allowed interception of API communications, routing credential traffic to an attacker-controlled server and logging API keys before the developer saw any warning.

The attack vector was not a vulnerability in the code. It was a vulnerability in the trust model applied to configuration.

The disclosure timeline tells its own story. The vulnerabilities were discovered in July 2025. They were patched in January 2026. Six months between discovery and fix, during which time any developer who cloned an affected repository was exposed.

Why the traditional security tooling cannot see this

This is the part of the story that matters most for security teams.

The standard application security toolkit is designed to find vulnerabilities in code. Static analysis examines source code for insecure patterns. Dependency scanners check libraries against known CVE databases. Secrets scanners look for hardcoded credentials in code files. Dynamic analysis tests the running application.

None of these tools model configuration files as part of the executable attack surface.

This is a reasonable design decision for the world these tools were built for — one in which configuration files defined behaviour but did not execute it. A .json file describing environment variables is passive data. It tells the application what values to use. It does not run code.

That assumption no longer holds.

In AI-assisted development environments, the configuration layer has become executable. Hooks run shell commands. MCP server definitions bootstrap external integrations. Project settings override consent mechanisms. The distinction between configuration and execution has collapsed, and the security tooling that was designed around that distinction cannot see what has changed.

To make this concrete:

1.  A SAST tool scans your source code for SQL injection, insecure deserialisation, and authentication weaknesses. It does not scan .claude/settings.json for shell commands that execute on clone.

2.  A dependency scanner checks your package.json or requirements.txt against CVE databases. It does not model the trust boundary between your MCP server configuration and the external services it connects to.

3.  A secrets scanner finds API keys hardcoded in source files. It does not detect a Hook configured to intercept and exfiltrate API credentials during normal operation.

4.  A SCA tool tracks your software bill of materials. It does not include the automation layer of your AI development tooling in that inventory.

The attack surface has moved. The tooling is scanning a different surface.

The supply chain dimension

The Claude Code vulnerability is an individual developer risk. The OpenClaw supply chain attack, which ran concurrently, demonstrates what the same principle looks like at ecosystem scale.

OpenClaw is an open-source AI agent framework that reached 200,000 GitHub stars within months of launch. Its package registry, ClawHub, hosts skills, extensions that extend what the agent can do. Security researchers found over 1,100 malicious skills in ClawHub, approximately one in five packages in the ecosystem.

Snyk identified 283 skills leaking credentials. 76 contained active malicious payloads. A critical vulnerability enabled one-click remote code execution.

SecurityScorecard found over 135,000 OpenClaw instances exposed to the public internet. Bitdefender detected OpenClaw deployments inside corporate networks, employees installing AI agents on company machines with full terminal and disk access.

The attack techniques were not new. Typosquatting. Automated mass uploads of near-identical packages with embedded payloads. These are the same techniques used in the npm and PyPI supply chain attacks of the past five years. What is new is the layer being targeted.

Traditional supply chain attacks target code. You install a package that contains malicious code. The code runs as part of your application.

AI agent supply chain attacks target the extension layer. You install a skill that contains a malicious payload. The payload runs with the permissions of the agent — which, in the case of OpenClaw, includes terminal access, disk access, and the ability to read your email and calendar.

The same attack techniques. A fundamentally different execution context. And almost no existing tooling designed to model it.

The architectural root cause

If you apply root cause analysis to the Claude Code vulnerability, not just to the specific CVE, but to the class of problem it represents, you arrive at an architectural condition that the patch does not address.

That condition is the assumption of configuration passivity.

Software architecture has, for decades, maintained a meaningful boundary between configuration and execution. Configuration files are data. They are read by the application. They do not run independently. This boundary shaped how trust is modelled: code is reviewed, signed, and scanned; configuration is managed but not treated as a code-equivalent attack vector.

AI development tooling has erased that boundary. When a configuration file can define shell commands that execute at lifecycle events, connect to external services, and override consent mechanisms, it is no longer passive data. It is executable infrastructure. It belongs in the same trust model as code.

The architectural question that should follow from this is not 'how do we patch this specific CVE?' It is:

Where else in our environment are we treating as passive something that has become executable?

For most organisations adopting AI development tooling, the answer is: in more places than they have inventoried.

MCP server configurations that connect AI agents to internal data sources. Prompt files checked into repositories that influence how coding assistants behave. Agent skill registries that extend what automation can do in production environments. CI/CD pipeline configurations that now include AI-powered steps with external service access.

Each of these is a configuration layer that has acquired execution authority. None of them are modelled as attack surface by the scanning tools most organisations have deployed.

What a genuine security response looks like

The patch is necessary. It is not sufficient.

A genuine response to this class of vulnerability requires three things that most organisations are not yet doing:

1. Inventory the configuration layer as attack surface

Every configuration file in your AI tooling environment that can trigger execution, bootstrap an external connection, or influence agent behaviour needs to be included in your security inventory. This is not a natural extension of your existing SBOM process. It requires a deliberate decision to model the configuration layer as executable infrastructure.

What to look for: Hook definitions that execute shell commands. MCP server configurations that connect to external services. Agent skill registries and their provenance. Prompt files checked into version-controlled repositories. CI/CD configurations that invoke AI-powered steps.

2. Model trust boundaries in the AI tooling layer

Your code security tool sees your code. Your cloud security tool sees your cloud. Neither one sees the boundary between your AI development tooling and the execution environment it operates in.

The trust boundary question to ask: what is this configuration file permitted to do, and in what context? A Hook that runs a linting command in a sandboxed development environment is a different risk profile from a Hook that can execute arbitrary shell commands on a developer's machine with production credentials in scope.

Mapping these boundaries, across code, configuration, and the execution context the tooling operates in, is the security work that scanning cannot replace.

3. Apply the same supply chain rigour to extensions as to dependencies

The ClawHub attack succeeded because organisations were applying less scrutiny to AI agent skills than to software dependencies. The provenance of a skill - who published it, when, whether it has been reviewed, what permissions it requests - deserves the same analysis that a security-conscious team applies to a new npm package.

This means: pin versions. Review permissions before installation. Monitor for anomalous behaviour in the extension layer. Treat ClawHub, and every equivalent registry that emerges, as supply chain surface.

The broader pattern

The Claude Code vulnerability is one instance of a structural shift that is happening across the entire AI development tooling landscape.

As AI tools acquire the ability to execute commands, initialise external integrations, and take autonomous actions in development and production environments, the configuration layer that governs their behaviour becomes part of the attack surface. This is not a flaw in any particular tool. It is the consequence of a design decision, granting AI tools execution authority, that the security industry has not yet fully modelled.

The tools that find code vulnerabilities were built for a world where execution lived in code. The tools that find supply chain vulnerabilities were built for a world where the supply chain was made of packages. Neither was built for a world where a configuration file in a repository can execute shell commands on the machine of anyone who clones it.

That world is here.

The tooling is catching up. In the meantime, the organisations that understand the architectural shift - not just the specific CVE - are the ones that will stop patching instances of a problem whose structural source has not changed.