A principal security researcher at LayerX disclosed a zero-click remote code execution flaw in Claude Desktop Extensions. He assigned it a CVSS 10.0. Anthropic's response: it falls outside their current threat model. There is no CVE. There is no patch.
Here's what actually happened, what it means, and what you can do about it right now.
What Is Claude DXT?
Claude Desktop Extensions — DXT for short — are Anthropic's packaging format for extending Claude Desktop with third-party capabilities. Think of them as plugins: a DXT can connect Claude to external services, grant it access to local tools, and bridge the gap between conversation and action on your machine.
DXTs integrate via the Model Context Protocol (MCP), the same protocol Claude uses for tool calling more broadly. When you install a DXT, you're giving Claude Desktop a new set of tools it can invoke — reading your calendar, accessing files, calling APIs, running local executables. The DXT format bundles an MCP server with metadata, permissions declarations, and an install manifest into a single distributable package.
The key architectural detail: DXTs run locally, on your machine, with your user-level privileges. They're not sandboxed in a container or isolated VM. When a DXT executes, it operates with the same access your user account has — your filesystem, your credentials, your network. This is by design. It's what makes DXTs useful. It's also what makes the vulnerability Roy Paz found significant.
The Vulnerability
On February 9, 2026, Roy Paz — Principal Security Researcher at LayerX Security — published a detailed disclosure of a zero-click remote code execution vulnerability in the DXT architecture. He assigned it a CVSS score of 10.0, the maximum severity rating on the Common Vulnerability Scoring System scale.
To be precise about what that score means: the CVSS 10.0 is Paz's own assessment based on the standard CVSS v3.1 framework. No CVE number has been assigned. There is no NVD entry confirming or contesting the score. The rating reflects the researcher's evaluation of attack vector (network), attack complexity (low), privileges required (none), user interaction (none), and impact (complete compromise of confidentiality, integrity, and availability).
The core of the flaw is a privilege escalation chain. A DXT that presents itself as a low-risk connector — something innocuous like a calendar integration or a weather widget — can chain its way to high-privilege local execution without additional user consent. Once installed, the extension can leverage its MCP server access to invoke tools and execute commands that go far beyond what the user believed they were authorizing.
The attack is zero-click in the sense that no further user interaction is required after the initial DXT installation. The user installs what looks like a harmless extension. The extension's MCP server, now running locally with user privileges, can execute arbitrary code. There is no secondary permission gate between "user installs DXT" and "DXT executes arbitrary commands on the user's machine."
The practical impact: an attacker who publishes a malicious DXT — or compromises a legitimate one — gets arbitrary code execution on every machine that installs it. File exfiltration, credential theft, persistent backdoor installation, lateral movement — the full menu of post-compromise activity becomes available through what the user thought was a calendar plugin.
(LayerX Security Blog, Cybersecurity News)
Anthropic's Response
Anthropic did not assign a CVE. They did not ship a patch. Their position, as communicated through spokesperson Jennifer Martinez to CSO Online, was:
> "Claude Desktop's MCP integration is a local development tool where users explicitly configure and grant permissions to servers they choose to run... We recommend that users exercise the same caution when installing MCP servers as they do when installing [other] third-party software."
Infosecurity Magazine paraphrased Anthropic's stance as classifying the vulnerability "outside our current threat model."
Let's be fair about what Anthropic is saying here. Their argument has internal logic: DXT installation is a deliberate user action. You choose to install an extension. You grant it permissions. The analogy to "installing third-party software" is not unreasonable on its face — when you install any application on your machine, you're trusting it with your user-level privileges.
But there's a meaningful difference between installing a standalone application and installing a DXT. When you install a macOS app, you have decades of ecosystem conventions, code signing, notarization, Gatekeeper warnings, and App Store review (if applicable) standing between you and arbitrary code execution. When you install a DXT, you're adding an MCP server that runs inside Claude Desktop's trust boundary, inheriting the AI agent's ability to take autonomous action. The DXT doesn't just run when you launch it — it runs when Claude decides to invoke its tools, potentially in contexts the user didn't anticipate.
The "treat it like any other third-party software" guidance also puts the entire burden of security evaluation on the end user. That's a defensible position for a local dev tool used by sophisticated developers. It's a much harder position to maintain as DXTs reach a broader audience and as the DXT ecosystem grows. Package managers solved this problem for code dependencies with registries, signing, and auditing infrastructure. The DXT ecosystem doesn't have any of that yet.
(CSO Online, Infosecurity Magazine)
Impact Assessment
Who's affected: anyone running Claude Desktop with third-party DXT extensions installed. The attack surface scales with the DXT ecosystem — every extension is a potential vector, and the ecosystem is growing rapidly.
What's at risk:
- Files and credentials. A malicious DXT has read/write access to anything your user account can touch. SSH keys, cloud credentials in
~/.aws, environment variables, browser session tokens — all accessible. - Source code and intellectual property. Developers are the primary DXT user base. Their machines contain proprietary codebases, API keys, database connection strings, and deployment credentials.
- Lateral movement. A compromised developer workstation is a beachhead into production infrastructure. SSH keys, VPN configs, and cloud IAM credentials on a dev machine can unlock access to production systems.
- Supply chain poisoning. A compromised DXT doesn't just affect the machine it runs on. If it can modify source code or inject dependencies, it can propagate through build pipelines to downstream users and production systems.
The trust model problem: The CVSS 10.0 score reflects the combination of network attack vector, zero user interaction (post-install), no privileges required (the attacker just needs to publish a DXT), and full impact across confidentiality, integrity, and availability. You can disagree with the specific score — reasonable security professionals might rate it differently depending on how they weight the "user chose to install it" factor — but the underlying risk is real regardless of the number.
The comparison to browser extensions is instructive. Chrome extensions went through the same evolution: an early permissive model, followed by ecosystem abuse, followed by mandatory review, granular permissions, and manifest v3 restrictions. The browser extension security model took years and multiple high-profile incidents to mature. DXTs are at the beginning of that curve.
What You Can Do Right Now
If you're using Claude Desktop with DXT extensions, here are concrete steps you can take today:
1. Audit your installed DXTs. Review every extension you've installed. Do you know who published it? Is the source code available for inspection? Remove anything you don't actively use or can't verify.
2. Review DXT source code before installing. If a DXT's source is available, read it. Look for network calls to unexpected endpoints, file system access outside its stated scope, and any command execution. If the source isn't available, that's a signal.
3. Monitor network traffic. Tools like Little Snitch (macOS) or Wireshark can show you what your DXT extensions are actually doing on the network. A calendar integration making HTTP requests to an unfamiliar IP address is a red flag.
4. Restrict DXT capabilities at the execution layer. This is where pre-execution interception matters. Anthropic's own architecture doesn't gate DXT tool calls after installation — once a DXT is installed, its tools are available to Claude without further permission checks. A pre-execution hook that sits between Claude's tool call decision and the actual execution can enforce policy rules on what DXT-initiated actions are allowed.
Shoofly Advanced does exactly this. The daemon runs as a background sidecar to Claude Desktop, and the hook intercepts tool calls before they execute. You define policy rules in open and auditable YAML — which DXT tools are allowed to run, what file paths they can access, whether they can make network requests, what shell commands are permitted. When a DXT extension tries to do something outside its policy, the call is blocked before it executes. Not logged after the fact. Blocked before it happens.
This isn't a fix for the architectural issue Paz identified. A pre-execution policy layer is a mitigation — it reduces the blast radius of a compromised DXT by restricting what it can actually do, even if it tries to escalate privileges. The underlying trust model issue in the DXT architecture is something only Anthropic can address.
5. Isolate Claude Desktop. If you're running Claude Desktop for work that touches sensitive systems, consider running it in a VM or container. This is the blunt-force approach, but it's effective — a compromised DXT in a VM can't reach your host filesystem or credentials.
The Bigger Picture: Extension Security in AI Agents
The DXT vulnerability isn't a one-off bug. It's a pattern.
AI agents are useful precisely because they can take action — run tools, execute code, access files, make API calls. Every extension expands the attack surface, and the more autonomously the agent operates, the less opportunity a human has to catch a malicious tool call before it executes.
We've seen this play out across the ecosystem:
- MCP servers: 30+ CVEs filed in 60 days [NEEDS SOURCE — verify exact count and timeframe]. The protocol that DXTs are built on has its own security crisis.
- Browser extensions: Chrome's manifest v3 migration was driven by years of extension abuse — data exfiltration, credential theft, ad injection. The AI agent extension ecosystem is replaying this history at accelerated speed.
- Package registries: The ClawHub registry found over 800 malicious skills in a single scan — roughly 8% of the registry at the time. Supply chain attacks on AI agent tooling are already happening at scale.
The industry response has been to push security to the model layer — better classifiers, smarter refusals, improved alignment. That work matters. But a perfectly aligned model that faithfully executes a tool call from a malicious extension is still executing the malicious tool call. The security boundary needs to exist at the execution layer, not just the model layer.
This is the thesis behind pre-execution security: intercept the tool call between the agent's decision and the tool's execution. Evaluate it against deterministic policy rules. Block it if it violates policy. As Paz's research demonstrates, the gap between "user installed the extension" and "extension can do anything" is where the real risk lives.
Anthropic's position on this isn't unreasonable for where they are today. Claude Desktop is, as they say, a local development tool. The DXT ecosystem is young. The user base is predominantly technical. These are fair points.
But ecosystems grow. User bases broaden. The gap between "intended for sophisticated developers" and "actually used by everyone" closes faster than security infrastructure gets built. If the DXT trust model doesn't evolve, the incidents will come — and they'll come from extensions that looked perfectly safe at install time.
Don't wait for Anthropic to fix this. Shoofly Advanced gives you policy rules that restrict what DXT extensions can do before they do it. Pre-execution interception via daemon and hook, open and auditable YAML policy rules, 100% local — no data sent externally. $5/mo.
*Related reading:*
Ready to secure your AI agents? Shoofly Advanced provides pre-execution policy enforcement for Claude Code and OpenClaw — 20 threat rules, YAML policy-as-code, 100% local. $5/mo.