MCPwn Is Live. We Scanned the Supply Chains of 14 MCP Servers.

MCPwn dropped this week. CVE-2026-33032 — CVSS 9.8, actively exploited, 2,600+ instances exposed. Two HTTP requests. No authentication. Full nginx server takeover.

Then MCPwnfluence: CVE-2026-27825 and CVE-2026-27826. The most widely used Atlassian MCP server — SSRF chained with arbitrary file write for unauthenticated RCE. Two requests, root on your machine.

Both disclosed by Pluto Security. Both named. Both actively exploited before patches shipped.

These are the first named MCP exploit campaigns. They won't be the last.

While the security community focuses on the exploits themselves, we asked a different question: what do the supply chains of MCP servers actually look like? If you're installing MCP servers to connect your AI assistant to GitHub, Slack, databases, and file systems — what are you actually trusting?

We scanned 14 MCP servers using Proof of Commitment, a behavioral supply chain scorer that analyzes maintainer depth, longevity, release cadence, and download momentum. Then we mapped their full dependency trees to depth 2.

The Exploited Servers

mcp-atlassian (MCPwnfluence) — Score: 42/100

mcp-atlassian — score: 42/100 | 1 maintainer | 334K downloads/wk | 1.4 years old

The most widely used Atlassian MCP server. Over 4,400 GitHub stars. 334K weekly downloads. One maintainer.

MCPwnfluence gave attackers unauthenticated RCE — SSRF to redirect internal requests, then arbitrary file write via the confluence_download_attachment tool with no path validation. Anyone on your local network could own your machine.

A commitment score of 42 with a single maintainer is a clear risk signal. Not because single maintainers are bad people — but because one person maintaining a package that connects your AI agent to your entire Atlassian instance is a concentration of trust that the ecosystem hasn't priced in.

mcp-remote — Score: 53/100

mcp-remote — score: 53/100 | 2 maintainers | 296K downloads/wk | 1.1 years old

CVE-2025-6514 — the OAuth connector used to bridge remote MCP servers. 558,000+ downloads at time of disclosure. OS command injection via OAuth discovery fields.

The package itself scores 53. But the supply chain tells a different story:

Supply chain: 11 nodes | 5 CRITICAL | 4 HIGH | 2 WARN
Worst score: 31 (strict-url-sanitise)

Five CRITICAL packages — all single maintainers with massive download counts:

Package	Downloads/wk	Maintainers	Flags
open	92M	1	CRITICAL
default-browser	31M	1	CRITICAL
define-lazy-prop	63M	1	CRITICAL + stale
is-inside-container	32M	1	CRITICAL + stale
wsl-utils	28M	1	CRITICAL + new (<1yr)

And then there's strict-url-sanitise — score 31, one maintainer, less than a year old, 644K weekly downloads, flagged HIGH. A URL sanitization library that's new, single-maintainer, and sits in the dependency tree of the package that handles your MCP OAuth flows.

excel-mcp-server — Score: 40/100

excel-mcp-server — score: 40/100 | 1 maintainer | 1.6M downloads/wk | 1 year old

CVE-2026-40576 — path traversal. One maintainer, 1.6 million weekly downloads, one year old. Score: 40. This is the profile.

Flowise — Score: 58/100

flowise — score: 58/100 | 10 maintainers | 3K downloads/wk | 3 years old

CVE-2026-40933 — authenticated RCE via MCP adapter. Flowise has 10 maintainers, which is healthier, but its supply chain at depth 2 reveals 41 nodes with google-auth-library (44M downloads/week, 1 maintainer) sitting in the CRITICAL path.

The Official Servers

Anthropic's official MCP servers score better on maintainer count (6 each) but worse than you'd expect on behavioral commitment:

Server	Score	Downloads/wk
@modelcontextprotocol/server-filesystem	63	325K
@modelcontextprotocol/server-github	52	119K
@modelcontextprotocol/server-slack	48	49K
@modelcontextprotocol/server-puppeteer	45	29K
@modelcontextprotocol/server-brave-search	42	28K

The filesystem server (CVE-2025-53109, CVE-2025-53110 — path traversal escaping the sandbox) scores 63. Not bad. But server-github at 52 is concerning for a package that gets access to your GitHub repos.

And the supply chain of server-github? 10 nodes, 5 CRITICAL:

Package	Downloads/wk	Maintainers	Risk
zod	159M	1	CRITICAL
@types/node	310M	1	CRITICAL
@types/node-fetch	20M	1	CRITICAL
zod-to-json-schema	39M	1	CRITICAL
universal-user-agent	27M	1	CRITICAL

zod — 159 million downloads per week, one maintainer — is in the dependency tree of almost every MCP server. It's the schema validation layer. If compromised, an attacker could modify the validation logic that determines which tool calls are accepted.

The Community Servers

Server	Score	Maintainers	Downloads/wk	Notes
supergateway	50	1	84K	MCP transport bridge
@azure-devops/mcp	45	3	0	CVE-2026-32211 (CVSS 9.1)
fastmcp	43	1	0	MCP framework
mcp-framework	43	1	0	MCP framework

The Azure MCP Server (@azure-devops/mcp) — CVE-2026-32211, CVSS 9.1, missing authentication entirely — scores 45. Three maintainers but zero weekly downloads on npm (it ships through other channels). The score reflects the behavioral reality: a young package with limited ecosystem commitment.

The Pattern

Here's what commitment scoring reveals across the MCP ecosystem:

Every exploited MCP server scored below 55. The average across all 14 servers we scanned: 50.

Every exploited server with an npm/PyPI package had a single maintainer or fewer than 3. mcp-atlassian: 1. excel-mcp-server: 1. mcp-remote: 2.

The supply chains are worse than the packages. mcp-remote looks acceptable at score 53, until you see 5 CRITICAL single-maintainer packages underneath it. server-github looks fine at 52 with 6 maintainers — until you see zod (159M downloads, 1 maintainer) in its tree.

This isn't a coincidence. MCP servers are:

1. Young — most are under 2 years old
2. Fast-growing — download counts are exploding
3. Under-maintained — single maintainers are the norm, not the exception
4. Heavily depended upon — they sit between your AI agent and your production infrastructure

This is exactly the profile that supply chain attackers target. The LiteLLM compromise (March 2026), the axios incident (April 2026), the mcp-remote exploit — all hit packages with this profile.

What Would Have Helped

Commitment scoring wouldn't have prevented CVE-2026-33032 (MCPwn) — that's a code vulnerability in a Go binary, not a supply chain issue. But for the npm/PyPI ecosystem:

• mcp-atlassian at score 42 with 1 maintainer should have been a flag before you connected it to your Confluence and Jira. Not "don't use it" — but "understand what you're trusting."
• mcp-remote's strict-url-sanitise at score 31 — a URL sanitization library younger than a year in your OAuth flow — is the kind of transitive risk that only shows up when you scan the tree.
• zod at 159M downloads with 1 maintainer isn't going away, but knowing it's in your MCP server's critical path changes how you monitor for unexpected releases.

The point isn't to avoid all risk. It's to know your actual attack surface instead of assuming that "widely used" means "safe."

Scan Your Own MCP Servers

CLI

# Score MCP server packages directly
npx proof-of-commitment mcp-remote @modelcontextprotocol/server-github

# Score PyPI MCP packages
npx proof-of-commitment --pypi mcp-atlassian excel-mcp-server

# Full supply chain analysis
curl -X POST https://poc-backend.amdal-dev.workers.dev/api/graph/npm \
  -H "Content-Type: application/json" \
  -d '{"package": "mcp-remote", "depth": 2}'

Web UI

Paste your package.json or enter a package name at getcommit.dev/audit.

CI (GitHub Action)

- uses: piiiico/proof-of-commitment@main
  with:
    fail-on-critical: false
    comment-on-pr: true

MCP Server

Add proof-of-commitment as an MCP server in Claude Desktop or Cursor to audit packages conversationally:

https://poc-backend.amdal-dev.workers.dev/mcp

---

Data collected April 18, 2026 using Proof of Commitment v1.1.0. Scores are behavioral commitment composites — not vulnerability scanners. A low score means concentrated trust, not confirmed compromise. Full methodology on GitHub.