MCP Server Security: 40+ CVEs and the Hardening Playbook

The Model Context Protocol was introduced by Anthropic in November 2024 as a universal plug standard for connecting LLM applications to external tools. By early 2026, it had accumulated over 150 million downloads, roughly 7,000 publicly accessible servers, and — per OX Security's April 2026 research — somewhere north of 200,000 vulnerable instances exposed to arbitrary remote code execution. That last number is not a theoretical upper bound. It is the result of a design decision Anthropic has explicitly declined to change.

Between January and April 2026, researchers filed over 40 CVEs against MCP implementations across Python, TypeScript, Java, and Rust SDKs. The pace of disclosure alone should be a signal: this is not a patch backlog from legacy infrastructure. It is a protocol that went from specification to production faster than the security community could audit it — and the attack surface is now being monetized in real time.

What the CVE Wave Actually Looks Like

The headline figure, 30 CVEs in the first 60 days of 2026, understates the problem. By April, the count had crossed 40, with nine of eleven MCP marketplaces found to ship at least one critically scored issue.

Endor Labs' analysis of 2,614 MCP implementations found:

• 82% use file operation APIs prone to path traversal
• 67% use APIs with code injection exposure
• 34% use APIs directly susceptible to command injection

Of the 518 officially registered MCP servers examined in parallel surveys, 38–41% offered no meaningful authentication.

The Command Injection Concentration

A breakdown of CVEs filed in early 2026, compiled by Practical DevSecOps, shows the vulnerability distribution:

Class	Share of Filed CVEs
Shell / exec injection	43%
Tooling infrastructure flaws	20%
Authentication bypass	13%
Path traversal	10%
Other / miscellaneous	14%

The 43% command-injection concentration is not accidental. MCP uses STDIO as its local transport mechanism. Spawned command strings inherit the process environment by default, and the protocol's specification places sanitization responsibility on each individual implementer rather than enforcing it at the SDK level. Every downstream MCP server author must independently arrive at the same correct answer — a security model that has historically not worked for any protocol at scale.

Representative CVEs Worth Tracking

CVE-2025-6514 (CVSS 9.6): An OS command injection in mcp-remote, the proxy package that allows Claude Desktop and similar hosts to communicate with remote MCP servers. A malicious server crafts an authorization_endpoint response that triggers arbitrary command execution on the client machine. The package had 437,000+ downloads before disclosure. Patched in version 0.1.16, released June 17, 2025.

CVE-2026-34935 (CVSS 9.8): A command injection in PraisonAI's MCP CLI handler. The --mcp argument is passed through shlex.split() into anyio.open_process() with no validation or allowlist at any hop, enabling full OS command execution as the process user. The initial patch was incomplete — a follow-on advisory (GHSA-9qhq-v63v-fv3j) documents missing argument allowlisting in the revised fix.

CVE-2026-33032 (CVSS 9.8): Architectural RCE in nginx-ui's MCP integration, reachable without authentication on default configurations.

The Architectural Problem Anthropic Won't Patch

In April 2026, OX Security published what they called the "Mother of All AI Supply Chains" — a finding that Anthropic's official MCP SDKs, across all four supported languages, use subprocess-based architecture as their core transport, spawning shell processes without mandatory sanitization. This is not a coding error in a third-party implementation. It is the reference design.

OX's research triggered over 30 responsible disclosures and 10+ High/Critical CVEs against downstream projects. When they escalated to Anthropic and recommended protocol-level remediation — changes that would have protected every downstream user — Anthropic declined to modify the architecture, describing the STDIO execution model as a "secure default" and stating that sanitization is the developer's responsibility.

The practical consequence: every MCP server author is now an independent security unit. There is no enforcement layer at the protocol or SDK boundary that prevents unsanitized subprocess execution. This pushes the full burden onto application teams who may not have AppSec expertise, and who are building against a specification that was designed for ease of integration, not defense-in-depth.

The NSA published a 17-page security guidance document on MCP deployments in May 2026 (U/OO/6030316-26), marking the first time a US intelligence agency has issued a formal threat model for AI agent plumbing. Its existence confirms the protocol has crossed from experimental tooling into critical enterprise infrastructure — whether most engineering leads treat it that way or not.

Chained Attacks: The Compounding Problem

Individual MCP server vulnerabilities are dangerous. But production agent deployments typically connect multiple servers simultaneously — filesystem access, database queries, external API calls, code execution — and this is where the risk compounds non-linearly.

Palo Alto Unit 42's research demonstrated that MCP's sampling feature — which allows servers to proactively request LLM completions — can be weaponized for resource theft, conversation hijacking across multiple turns, and covert tool invocation invisible to the user. When five MCP servers are connected in a single agent context, Unit 42 measured a 78.3% attack success rate for chained exploitation scenarios, with a 72.4% cascade rate across servers in the same agent once one server is compromised.

The mechanism is architecturally simple: a malicious or compromised server injects instructions into the conversation log that persist beyond the initial interaction. Because the LLM treats these as part of its context window, subsequent tool calls by other MCP servers execute under attacker-controlled premises. No user interaction is required after the initial compromise.

This is not a theoretical attack class. It maps directly to the tool-poisoning pattern already documented in OWASP's MCP Top 10 and in the academic analysis at arXiv:2601.17549.

Shai-Hulud and the Supply Chain Amplifier

The vulnerability wave in MCP servers does not exist in isolation. It sits inside a broader software supply chain where dependency currency is measured in months, not days.

Datadog's State of DevSecOps 2026 — drawn from tens of thousands of production environments — found:

• 87% of organizations run at least one known exploitable vulnerability in deployed services
• The median dependency is 278 days behind its latest major version (up from 215 days in 2025)
• Java services lag by 492 days at the median; Ruby by 357 days
• 59% of Java services carry at least one exploitable vulnerability

As Help Net Security summarized, the problem is not awareness — it is the structural absence of automated update pipelines with adequate test coverage.

Into this context, TeamPCP launched the Shai-Hulud worm. The original Shai-Hulud attack in September 2025 compromised 180+ npm packages via a self-replicating mechanism: when a compromised package encountered npm authentication tokens in the environment, it automatically published malicious versions of every package it could reach. Unit 42 tracked over 500 packages compromised in that initial wave.

In May 2026, TeamPCP returned with Mini Shai-Hulud. The group open-sourced the worm's code on GitHub, with repository descriptions reading "Shai-Hulud: Open Sourcing The Carnage." Within days of publication, the repos had accumulated 39+ forks and were being reused by independent actors. The May 2026 campaign compromised 400+ packages across 172 distinct npm packages within five hours of deployment, hitting TanStack, Mistral AI, Guardrails AI, and SAP CAP tooling.

What makes the MCP connection explicit: Mini Shai-Hulud specifically targets ~/.claude.json, MCP server configuration files, and injects .claude/settings.json SessionStart hooks for persistent re-execution that survive npm uninstall. Phoenix Security's analysis found the malware masquerading as a legitimate MCP tool provider and registering three tools, each embedding a prompt injection to read ~/.ssh/id_rsa, ~/.aws/credentials, and .env files — staging them for exfiltration.

The attack targets Claude Code, Claude Desktop, Cursor, VS Code Continue, and Windsurf. If your MCP toolchain runs on npm packages with maintainer tokens in CI, your agent's tool-invocation context is a credential store.

What to Harden Now

The following is a concrete baseline for engineering teams running MCP servers internally or evaluating third-party ones. This is not an exhaustive checklist — it is the minimum viable security posture given what is actively being exploited.

Scoped Tokens and Least-Privilege Tool Definitions

MCP servers should receive scoped credentials for exactly the operations they need, with no ambient access to broader secrets.

# Example: scoped env block in your MCP server manifest
server:
  name: filesystem-reader
  version: "1.2.0"
  tools:
    - name: read_file
      allowed_paths:
        - /app/data/readonly/**
      deny_patterns:
        - "**/.env"
        - "**/credentials*"
        - "**/.ssh/**"
        - "**/.aws/**"
  environment:
    # Pass only what this server needs — no AWS_SECRET_ACCESS_KEY here
    APP_READ_TOKEN: "${APP_READ_TOKEN}"

Never mount ~/.aws, ~/.ssh, or .npmrc into the MCP server process environment. If you are using Docker, use --env-file with a minimal env file, not --env-file ~/.env.

Allowlisted Tools Per Agent Context

Do not load every registered MCP server into every agent context. Allowlist the specific tools each workflow requires.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/app/data"],
      "allowedTools": ["read_file", "list_directory"],
      "blockedTools": ["write_file", "create_directory", "move_file"]
    }
  }
}

If your MCP host supports tool-level allowlists (Claude Desktop does via settings.json), enforce them. An agent that only needs to read files should not have access to a shell execution tool in the same session.

Sandboxed Execution

Run MCP servers as isolated processes with no network egress by default. For production deployments:

# Run the MCP server in a network-isolated container
docker run \
  --network none \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --env-file /etc/mcp/server.env \
  your-org/mcp-server:pinned-sha256

Pin container images to digest hashes, not tags. The Mini Shai-Hulud campaign compromised tagged versions within minutes of publication.

Log Tool-Invocation Chains

Tool calls should be logged with full context: which agent session triggered the call, which MCP server handled it, what arguments were passed, and what the return value was (redacted where sensitive). This makes post-incident reconstruction tractable.

At minimum, emit structured logs with:

{
  "event": "mcp_tool_invocation",
  "session_id": "sess_abc123",
  "server": "filesystem-reader",
  "tool": "read_file",
  "args": {"path": "/app/data/config.yaml"},
  "caller_model": "claude-sonnet-4-6",
  "timestamp_utc": "2026-05-29T08:12:34Z",
  "duration_ms": 42,
  "exit_status": "ok"
}

Pipe these to your SIEM. Unit 42's finding that multi-server chaining achieves a 78.3% attack success rate means a single compromised tool call is not your threat model — a sequence of them is.

Signed Tool Manifests

Before loading an MCP server definition, verify that the manifest has not been tampered with. The NSA's May 2026 guidance explicitly recommends requiring signed provenance checks for dynamic discovery. If you are pulling MCP server definitions from a registry, treat that registry as a third-party dependency: pin by hash, verify signatures, and alert on unexpected updates.

# Verify MCP server manifest signature before loading
cosign verify-blob \
  --certificate-identity "mcp-server@your-registry.com" \
  --certificate-oidc-issuer "https://accounts.google.com" \
  --signature mcp-server.sig \
  mcp-server-manifest.json

Update Cadence

Given Datadog's finding that the median Java dependency is 492 days out of date, and the NSA's recommendation to patch CVEs within 48 hours of disclosure, the gap between guidance and practice is roughly three orders of magnitude. For MCP servers specifically — where CVE-2026-34935 was initially issued an incomplete patch — subscribe to the GitHub Security Advisory feed for every MCP package you run:

gh api /repos/MervinPraison/PraisonAI/security-advisories \
  --jq '.[].ghsa_id' | head -5

Set up Dependabot or Renovate with merge-on-green for MCP packages at patch and minor version levels. Require AppSec sign-off only for major version bumps.

Protect Your CI/CD Token Boundary

The Shai-Hulud attack propagates via npm tokens found in CI environments. Audit your CI secrets:

• Rotate npm publish tokens to granular, package-scoped tokens (npm introduced package-level token scoping in 2024)
• Use GitHub Actions' permissions: {} block to default all jobs to read-only, explicitly granting only required permissions
• Enable StepSecurity's Harden-Runner or an equivalent network egress monitor on CI jobs that run npm install

# GitHub Actions job with minimal permissions and network monitoring
jobs:
  build:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: step-security/harden-runner@v2
        with:
          egress-policy: block
          allowed-endpoints: |
            registry.npmjs.org:443
            github.com:443

Takeaways

The MCP vulnerability crisis is not a bug-count story. It is a structural one. A protocol designed for developer experience, with sanitization responsibility explicitly delegated to each individual implementer, was deployed at scale before the security community could audit it. The result is a predictable distribution: 40+ CVEs in four months, a 43% command-injection rate across audited servers, and a self-replicating worm that specifically targets the configuration files your agents use at runtime.

Concrete actions for engineering leads:

• Audit every MCP server your agents load. For each one, verify the installed version against its GitHub Advisory feed and check for open CVEs on NVD.
• Apply tool-level allowlists per agent context. An agent that reads files should not also have shell access in the same session — this is the single highest-ROI configuration change.
• Inspect your CI token boundary. Rotate npm and GitHub tokens to scoped, package-level credentials. Check for .npmrc and .env files in Docker build contexts.
• Check ~/.claude.json and .claude/settings.json for unexpected SessionStart hooks. The Mini Shai-Hulud campaign plants persistence there that survives npm uninstall.
• Treat MCP server manifests as third-party dependencies. Pin to digest hashes. Verify signatures before loading. Treat unexpected tool definition changes as potential tampering.
• Log tool-invocation chains to your SIEM. Multi-server chaining is the primary attack surface. You cannot detect it without sequence-level visibility.

The NSA publishing a threat model for AI agent plumbing in May 2026 is a reasonable signal that this infrastructure category has crossed into critical territory. Act accordingly before your next agent deployment.