MCP security: the risks that matter

What are the security risks of an MCP server?

The real security risks of an MCP server fall into three groups: supply-chain risk in the code of a packaged server you install and run, endpoint and operator risk in a remote server you connect to, and prompt-injection risk that both kinds share. The common thread is that an MCP server is not a passive data source. It exposes tools an autonomous agent can call and, if packaged, code that runs on your machine, so a compromised or careless server has a direct path to your data and your systems. This page is the threat model VerifyMCP scores against, and each risk below maps to a signal in one of the two scoring rubrics.

Packaged servers: supply-chain risk

A packaged server (npm, PyPI, NuGet, OCI, MCPB) is a dependency you install and execute. The risks are the classic software supply-chain risks, amplified because agents install servers quickly and often:

Malware: a package that is outright malicious, or that was hijacked (account takeover, typosquat, dependency confusion).
Vulnerable dependencies: known CVEs in the package or its transitive tree that an attacker can exploit.
Install-time code execution: postinstall/build scripts that run before you’ve executed a single intentional line.
No provenance: you can’t prove the published artifact was built from the source you’re reading, so a malicious build can hide in plain sight.
Unmaintained code: an abandoned package accrues unpatched vulnerabilities and is a prime account-takeover target.

Remote servers: endpoint & operator risk

A remote server is a hosted endpoint you connect to. You don’t run its code, so the risk shifts to the connection and the operator:

Weak or broken transport security: expired/invalid TLS, protocols below TLS 1.2, or plaintext HTTP that exposes your traffic to interception.
Missing authentication: an endpoint that accepts tool calls with no authorization, or only a token challenge with no proper protected-resource metadata.
Unverifiable identity: no DNSSEC, no HSTS, nothing that ties the endpoint to an accountable operator.
Instability: tools and schemas that change underneath you, breaking agents or silently altering behaviour.

Prompt-injection and tool-poisoning (shared risk)

Both kinds of server can carry prompt-injection risk: tool descriptions, results, or resources are text the model reads, and malicious content there can hijack an agent. VerifyMCP can’t read your private data flows, but the signals it can verify (schema quality, descriptions, stability, provenance) correlate with servers that are built with care.

How this maps to the score

Every risk above corresponds to signals in one of the two rubrics:

npm / package rubric: supply-chain and provenance signals.
remote endpoint rubric: transport, endpoint security, capabilities, schema and stability signals.

And every signal that can fail has a fix guide with concrete steps. Start at the docs home or jump to the finding shown on a server’s page.