MCP Servers and Claude Plugins Share One Unvetted Trust Boundary

One click, many capabilities

Anthropic sells Claude's extension features as separate building blocks: Skills, Connectors built on the Model Context Protocol (MCP), hooks, and Plugins. Security researchers increasingly treat them as one attack surface. Pluto Security argues these primitives behave as a single bundle. Installing one plugin can activate skills, MCP servers, hooks and arbitrary binaries behind one opaque consent prompt, and approving the top of that stack implicitly approves everything beneath it 3. Pluto says most users grant that transitive trust without ever listing what they are enabling 3.

This framing ties together several findings that might otherwise look like isolated bugs. Taken together, they suggest the weakness is architectural and not a matter of individual coding mistakes.

Repository files as an execution path

The most concrete evidence comes from Check Point Research. It disclosed critical vulnerabilities in Claude Code, tracked as CVE-2025-59536 and CVE-2026-21852. Malicious project configuration, using hooks, MCP server definitions and environment variables, could run arbitrary shell commands and exfiltrate Anthropic API keys when a developer cloned and opened an untrusted repository 1.

The Cloud Security Alliance places this in a broader industry pattern. It reports that multiple AI coding assistants, including Amazon Q Developer as well as Claude Code, were vulnerable to malicious git repositories that could execute commands and steal cloud credentials with no user action beyond opening the project 2. The root cause it identifies is a shared design choice: in affected versions, MCP server configurations stored in repository files were initialized automatically when a project opened, before any trust check ran 2. The CSA also cites GitGuardian's 2026 Secrets Sprawl report, which counted 24,008 unique exposed secrets, as context for how much credential material sits within reach of such attacks 2.

Why MCP widens the blast radius

Red Hat's guidance on plugin security explains why MCP deserves particular attention. When a plugin registers an MCP server, part of the attack moves off the repository altogether. Whoever controls that server can change what it returns without a commit, a code review or a CI run 4. A plugin that pins a server URL is trusting an endpoint run on someone else's terms 4.

Red Hat lists three properties that make this a threat model and not a theoretical concern. Nothing runs in a sandbox, so every component inherits the user's full permissions. Updates carry no verification, with no version pinning and no content hash. And reinstalling pulls whatever currently sits on the default branch, so one malicious commit reaches every later installer 4. SKILL.md files add a related risk, because their Markdown is injected directly into the model's instructions 4.

Pluto adds that the execution surface matters as much as the content. The same SKILL.md that runs sandboxed through the Claude API inherits full local host privileges when executed in Claude Code 3.

Official marketplace, real exploits

These are not only lab scenarios. Pluto reported an end-to-end issue in an Anthropic-published plugin, Hookify, distributed through the official Claude Code marketplace. A single repository file steered Opus 4.6 into dumping environment variables and reading .env.local. Pluto says five payloads were tested, all five were followed, and none was flagged as prompt injection 34. Its write-up raises the question of whether Anthropic considers this behavior "working as designed" 3.

Other testing points to weak visibility. According to stork.ai's summary of Pluto's work, function-hook mods could read credentials and session history and send them to an attacker's server without showing the user any prompt. The built-in claude plugin details inspector could even report such a mod as having zero hooks 5. Dash.security separately showed that because mod code runs inside the Claude Code process, endpoint security tools see only a legitimate Claude process and cannot tell malicious activity from normal agent behavior 5. Anthropic's own security-default guard reportedly loads only on Team or Enterprise plans or under managed settings, which leaves individual developers largely unprotected 5.

The takeaway

The sources differ in emphasis. Check Point and the CSA focus on auto-execution flaws that can be patched, while Pluto, Red Hat and the stork.ai report describe a trust model that is risky by design. These views are consistent with each other. Fixing individual CVEs closes specific doors, but the underlying arrangement remains: one consent covers unsandboxed, unpinned code and remote MCP endpoints whose behavior can change silently.

Until Anthropic adds sandboxing, integrity checks and accurate capability disclosure across all plans, the practical stance is to treat every plugin, skill and MCP server as code with your full privileges. Teams should review each component individually, pin versions where possible, and avoid opening untrusted repositories in an agent that has access to real credentials.