A dependency finding is a signal. It is not the end of the analysis.
That matters for MCP because the installed tree can contain vulnerable code that never runs in a given server configuration. It can also contain vulnerable code on exactly the path an agent uses to call tools, move data, or reach a credential-bearing backend.
Those are different risks. Treating them the same creates noise. Ignoring both creates blind spots.
The useful middle ground is runtime reachability validation.
The three buckets
When a scanner finds a vulnerable package in an MCP server's installed tree, place it into one of three buckets.
Dependency-only signal. The package is installed, but the affected code path is not used by the MCP server in the observed configuration.
Reachable hardening issue. The affected dependency or risky behavior is on a server path, but exploit impact depends on deployment choices, credentials, input shape, or maintainer context.
Confirmed reachable issue. Safe local testing shows that normal MCP traffic or a relevant boundary request reaches the affected behavior.
This classification makes a report more useful for maintainers and less misleading for buyers.
What reachability means in MCP
For a normal web app, reachability often means "can an attacker send input to the vulnerable endpoint?"
For MCP, there are more paths:
- Tool request handling.
- Tool response parsing.
- Resource reads.
- Prompt and template handling.
- Local HTTP transport.
- Remote streamable HTTP transport.
- SSE compatibility paths.
- File upload paths.
- Outbound API clients.
- Browser automation sessions.
- Credential-bearing backend calls.
The question is not only "is this dependency installed?" It is "does this dependency handle an action the agent can cause?"
Why shallow scans miss important MCP risk
Top-level package scanning asks a narrow question: does the named package have an advisory?
That can be honest and still incomplete. Many MCP servers are thin wrappers around SDKs, HTTP clients, parsers, browser libraries, and vendor API clients. The advisory may sit one or more levels below the package a user typed into npx, uvx, pip, or a config file.
The installed tree is closer to runtime truth.
But even the installed tree is only step one. Once the tree is known, the next useful step is path validation.
A practical validation workflow
- Record the package version, lockfile, and dependency path.
- Identify the MCP entrypoint.
- List the tools, resources, prompts, and transports.
- Start the server locally with dummy credentials.
- Route outbound calls to a dummy endpoint where possible.
- Call normal MCP tools and record which client paths are reached.
- Send boundary requests that should be rejected.
- Classify each advisory separately.
One dependency can have several advisories, and only some may apply to the specific MCP server. A transport advisory should be evaluated against the server's actual transport mode. An HTTP client advisory should be checked against the outbound client path the server actually uses.
What a good public claim looks like
Public writing should avoid turning private validation into premature named accusations.
A good aggregate claim:
In our validation work, we found that some installed-tree findings are only dependency signals, while others sit on active MCP transport or tool-call paths.
A better technical claim:
For one local MCP HTTP configuration we tested, a boundary request with unrelated host or origin metadata reached the MCP initialize path instead of being rejected.
A bad claim:
Every package with this vulnerable dependency is exploitable.
The whole point of validation is to avoid that kind of overreach.
What this means for teams
If you are operating MCP servers, do not stop at a green package scan.
- Which package versions are installed on disk?
- Which vulnerable dependencies are present?
- Which of those dependencies sit on MCP-exposed paths?
- Which paths carry credentials?
- Which transports are enabled?
- Which boundary checks are enforced?
- Which findings are dependency-only, hardening issues, or confirmed reachable issues?
For agent infrastructure, the question is not just "what is installed?"
It is "what can the agent cause this installed code to do?"