The MCP package looked clean. The installed tree did not.

Bindfort — Fri, 15 May 2026 21:18:38 +0000

We audited 31 MCP server packages across npm and PyPI.

For each one, we ran two checks:

a direct check of the top-level package
a scan of the installed dependency tree
The direct package check found 1 finding.

The installed trees found 69.

Findings by scan view

That difference is the story.

MCP servers are installable tool surfaces. When an operator installs one, the package manager resolves a runtime tree. That tree can contain vulnerable dependencies even when the top-level package has no finding attached to it.

In this run, 11 of 31 installed trees had at least one finding. Across those trees, we saw 54 unique vulnerabilities: 2 critical, 34 high, 28 medium, 4 low, and 1 unknown severity.

This does not mean every finding is exploitable in every deployment. It does mean a shallow package check answers a narrower question than operators usually need answered.

The Scan Shape
The population covered 21 npm packages and 10 PyPI packages.

Each target produced two records:

The installed-tree findings were not just low-severity noise:

Installed-tree severity mix

The Operational Lesson
For MCP, the thing worth scanning is not only the package identifier.

It is the installed tree.

That means:

resolve the package
install it in isolation
capture the actual installed version
scan runtime dependencies
record registry metadata such as deprecation and yanked-release status
This matters because MCP is not confined to npm. In this audit, almost one-third of the targets were PyPI packages. Any MCP scanning program that only understands npm is incomplete by design.

Why This Version Is Aggregate
This version keeps target names out of the article. Some results are tied to active maintainers, so named evidence should go through direct notification first.

The aggregate finding is still actionable:

Direct package checks are not enough for MCP infrastructure. Operators need installed-tree scans.

That is the part teams can fix today.

Bindfort Research is expanding this work into a broader MCP ecosystem audit. Maintainers and operators who want to compare results privately can contact research@bindfort.com.

Your MCP dependency scan can pass and still miss HIGH vulnerabilities

Bindfort — Wed, 13 May 2026 13:36:32 +0000

Quick story, then the practical part.

We scanned five official MCP reference servers from the @modelcontextprotocol npm namespace. Standard tooling against the package manifest:

0 findings

Then we re-ran the same check against the installed dependency tree:

10 HIGH findings

Same five servers. Same advisory database. The difference was that the second scan walked into a package the first one never had reason to query: @modelcontextprotocol/sdk@1.0.1.

The advisories were public. The fixes were already shipped. The scan just didn't reach that far down.

What we scanned

The five official reference servers, on April 26, 2026:

@modelcontextprotocol/server-filesystem
@modelcontextprotocol/server-github
@modelcontextprotocol/server-everything
@modelcontextprotocol/server-memory
@modelcontextprotocol/server-sequential-thinking

The scan walked the full installed tree using npm ls --json --all, then sent every resolved package/version pair through OSV.dev.

What turned up

Every server resolved the same SDK version:

@modelcontextprotocol/sdk@1.0.1

That version sits behind two public HIGH advisories:

Advisory	Issue	Fixed in
`GHSA-8r9q-7v3j-jr4g`	ReDoS in the SDK parser	`@modelcontextprotocol/sdk@1.25.2`
`GHSA-w48q-cv73-mx4w`	DNS rebinding from missing default `Host` validation	`@modelcontextprotocol/sdk@1.24.0`

Two advisories × five servers = ten HIGH findings.

Why these matter (more than usual)

The ReDoS one is the interesting one. It's triggerable through an MCP tool response, not through a normal inbound HTTP request. A compromised or malicious upstream server can return crafted content and pin the calling agent's Node.js event loop. That's the opposite direction from where most application security tooling looks.

The DNS rebinding one is more familiar but still serious in this context. A user has an MCP server running locally. They open a browser tab. After DNS rebinding, attacker-controlled JavaScript can reach the local MCP server and call exposed tools. Filesystem, shell, repo, database — whatever the server hands out.

No malware. No privilege escalation. A browser tab and a service that didn't validate Host.

Why the shallow scan returned clean

The @modelcontextprotocol/server-* packages don't have GHSA entries on themselves. Ask a top-level scanner about them and you'll get back exactly what you asked for:

@modelcontextprotocol/server-filesystem  →  0 findings
@modelcontextprotocol/server-github      →  0 findings
@modelcontextprotocol/server-everything  →  0 findings
@modelcontextprotocol/server-memory      →  0 findings
@modelcontextprotocol/server-sequential  →  0 findings

What's actually on disk looks more like this:

@modelcontextprotocol/server-filesystem
  └─ @modelcontextprotocol/sdk@1.0.1
       ├─ GHSA-8r9q-7v3j-jr4g
       └─ GHSA-w48q-cv73-mx4w

Same database, same packages, different scan depth.

Shallow package scan:  5 × 0  =  0 findings
Recursive tree scan:   5 × 2  = 10 HIGH

The check you can run right now

From inside the project (or installed server directory):

npm ls @modelcontextprotocol/sdk --all

Installed SDK version	Status
`<1.24.0`	Both advisories present
`1.24.0` through `1.25.1`	DNS rebinding patched; ReDoS still present
`>=1.25.2`	Both advisories patched

If the lockfile still pins 1.0.1, just bumping package.json won't help. Update the lockfile, reinstall, and confirm with npm ls that the resolved version actually changed.

What a better scanner has to do

For npm-based MCP servers, the useful target is the installed tree:

npm ls --json --all

Then walk it recursively and query every node:

func walkNPMTree(tree map[string]npmTreeNode, out *[]DependencyInput) {
    for name, node := range tree {
        if name != "" && node.Version != "" {
            *out = append(*out, DependencyInput{
                Name:      name,
                Version:   node.Version,
                Ecosystem: "npm",
            })
        }
        if len(node.Dependencies) > 0 {
            walkNPMTree(node.Dependencies, out)
        }
    }
}

For a typical MCP server install that yields around 179 dependency records. Send them through OSV's batch endpoint and the SDK shows up as one of the records that returns hits.

The --all flag matters: without it, npm collapses deduped packages and you can lose parts of the resolved tree.

Closing note

This isn't a zero-day. The advisories are published, the fixes exist, and we're not the first to notice either one.

The point is more boring and probably more useful: known-vulnerable code can sit one level below the package your scanner checked, and "scan passed" doesn't always mean "tree is clean." For MCP, that's worth getting right before pointing an agent at production.

Full write-up and contact: https://bindfort.io/blog/mcp-transitive-cve-scan-2026

DEV Community: Bindfort