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:

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

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