5 of 5: Every Official MCP Server We Audited Carries Known-Vulnerable Transitive Dependencies

We scanned every reference MCP server in the official @modelcontextprotocol npm namespace using Bindfort's deep transitive CVE scanner. Five servers, five hits. Every single one resolves @modelcontextprotocol/sdk@1.0.1 as a transitive dependency - a version carrying two open HIGH-severity GHSAs, one enabling denial-of-service from a crafted tool response, one enabling silent browser-based tool invocation against a user's localhost.

Standard SCA tooling - the kind that most teams already have - returned zero findings on all five servers. Only a full recursive dependency tree walk surfaced the exposure. That gap is the problem.

Background

Model Context Protocol has become the default integration layer between AI agents and the tools they operate. Claude Desktop, Cursor, and a growing number of agentic frameworks all consume MCP servers - often the official reference implementations - to provide agents with access to filesystems, code, APIs, and data. The @modelcontextprotocol namespace on npm is where teams start.

Supply chain risk in agentic infrastructure is qualitatively different from the web-app case. When a vulnerability lets an attacker influence the tool responses an agent reads, it isn't just data exfiltration - it's prompt injection at the infrastructure layer. The surface is new; the tools defending it haven't caught up.

Methodology

Each server was scanned two ways to expose the gap between deep and shallow analysis:

• Deep (npm tree): BinaryInspectFetcher runs npm ls and walks every transitive node recursively
• Shallow (PURL): PURLFetcher queries the top-level package by name and version only - equivalent to what most SCA tools do by default

Findings

5 of 5 servers. 10 HIGH findings. 0 findings from shallow scan.

All ten findings collapse to two advisories on a single transitive package: @modelcontextprotocol/sdk@1.0.1.

GHSA-8r9q-7v3j-jr4g - ReDoS in MCP TypeScript SDK

Severity: HIGH  /  Fixed in: @modelcontextprotocol/sdk@1.25.2  /  Version lag: 25 minor releases

The SDK's message parser contains a regex with catastrophic backtracking behaviour. An attacker who controls an upstream MCP server - or who can inject content into a tool's response - can send a carefully crafted string that pins the Node.js event loop indefinitely. Any agent process running through this SDK version becomes unresponsive.

This is exploitable from the tool-response side: the attack arrives through the output of a tool call, not through an inbound request, which means perimeter controls that only inspect inbound traffic miss it entirely.

The fix has existed since sdk@1.25.2. The servers installed today still resolve 1.0.1.

GHSA-w48q-cv73-mx4w - DNS Rebinding Protection Not Enabled by Default

Severity: HIGH  /  Fixed in: @modelcontextprotocol/sdk@1.24.0  /  Version lag: 24 minor releases

Without Host header validation on the SDK's HTTP listener, the DNS rebinding attack is trivially executable. An attacker serves a webpage, the user's browser resolves the domain, the browser's DNS TTL expires, the attacker rebinds their domain to 127.0.0.1. From that point the attacker's JavaScript can open a connection to the MCP server running on localhost - same-origin policy no longer applies because the domain and the target are now the same host in the browser's view. The attacker can enumerate every tool the server exposes, call them, and read the results, with the full privileges of whatever process is running the server.

Critically: this requires no malware installation, no elevated privileges, no user interaction beyond visiting a webpage. The attack is browser-native.

The fix has existed since sdk@1.24.0. The servers installed today still resolve 1.0.1.

Why Your Scanner Probably Missed This

The top-level @modelcontextprotocol/server-* packages have no GHSA entries of their own. A scanner that queries each package by name and version - which is what PURL-based SCA, Dependabot, and most CI advisory checks do - returns a clean bill of health. This is not a failure of the advisory database; the advisories are accurate and up to date on OSV. It is a failure of scan depth.

You have to walk the full npm ls tree recursively to reach sdk@1.0.1. The servers declare @modelcontextprotocol/sdk as a direct dependency, but npm resolves it to 1.0.1 - an old pinned version that predates both fixes - and that resolved version is what ends up in the transitive tree. The top-level declaration and the installed transitive version are different. Shallow scanners read the declaration; deep scanners read what's actually on disk.

Shallow (PURL):  5 servers x 0 findings = 0
Deep (npm tree): 5 servers x 2 findings = 10 HIGH

What This Means for Teams Running MCP Servers

• Agents calling external or semi-trusted MCP servers are in scope for the ReDoS vector. A compromised upstream server can DoS the calling agent process through a crafted response.
• MCP servers bound to localhost (the majority of development and desktop configurations) are in scope for the DNS rebinding vector from any browser the user opens while the server is running.
• Containerized production deployments with no browser context reduce the DNS rebinding surface substantially, but the ReDoS exposure remains.

Mitigation: audit your installed node_modules tree - not just package.json - confirm @modelcontextprotocol/sdk resolves to >=1.25.2, and regenerate the lockfile if it doesn't.

npm ls @modelcontextprotocol/sdk --all

Reproduce

Everything below runs from a clean checkout. Full results in five minutes.

# Build the scanner
go build -o bin/bindfort.exe ./cmd/bindfort

# Start the admin API
BINDFORT_API_KEY=sg_demo_$(openssl rand -hex 16) \
  ./bin/bindfort.exe serve-admin --addr :18080 --db ./var/demo.db &

# Run the five-server bootstrap
BINDFORT_ADMIN_ADDR=http://localhost:18080 \
BINDFORT_API_KEY=$BINDFORT_API_KEY \
  go run ./tests/cve-scan-bootstrap

# Read findings
cat tests/cve-scan-bootstrap/out/_summary.json

Frozen baseline for diffing: tests/cve-scan-bootstrap/out-baseline-2026-04-26/

Disclosure Notes

Both GHSAs are already public on OSV.dev and the GitHub Advisory Database. This report does not disclose a new vulnerability - it documents that the standard toolchain people use to defend against known vulnerabilities fails to surface them for this specific package topology. The gap is the story.

We have not contacted the MCP maintainers separately because the advisory and fix are already published. The action item for teams is operational, not a coordinated disclosure: check your installed tree.

Compare Notes With Us

We're building a longitudinal registry of MCP server supply-chain posture and want to expand the audit to community and third-party servers beyond the official namespace. If you maintain an MCP server, run agents that consume them, or operate an AI platform with MCP integrations, we'd like to hear what you're seeing.