How to vet an MCP server before you install it

On 15 September 2025 someone published an npm package called postmark-mcp. It copied the code of a real Postmark integration. Two days later, version 1.0.16 added a single line: every email sent through the tool was also copied to an outside address. Security firm Koi wrote it up on 25 September, and the package was unpublished the same day.

Nothing about it looked unusual if you only glanced at the name. The point isn't that someone got fooled. It's that the checks that would have caught it take a few minutes: where the install command came from, how old the package was, and what changed in the last version.

This post is a ten-point check for any MCP server you're about to run, with the real incident behind each point. It is for people who install servers, not people who write them. For the writing side, see how to write MCP tool descriptions.

Whose job is it?

Yours, according to the project's own documents. The MCP project's security policy says clients trust the servers they connect to, local servers are trusted like any software you install, and users and administrators are responsible for choosing them. It also treats a stdio server's ability to run commands as intended behavior, not a vulnerability.

Two other facts are worth having in your head.

• A registry listing proves who owns a namespace. It doesn't prove safety. The official registry's moderation policy tells consumers to assume minimal to no moderation. It removes malware, spam and servers that don't work, and it doesn't remove servers that are merely low quality or vulnerable.
• "Official" is not a security rating. The reference servers in the project's own servers repository say in their README that they are examples, not production-ready. They keep getting advisories: the Filesystem and Git servers both had security bugs in 2025, and in late October 2026 new advisories landed for the Filesystem server (path validation) and the Fetch server (SSRF guards).

What has actually gone wrong

These are public, and each links to a primary source in the list at the end. They fall into six kinds of failure.

Look-alike packages. postmark-mcp (September 2025) is the best-known. A second case: an unscoped npm package named mcp-server-github squatted the name of the official, scoped @modelcontextprotocol/server-github. Two versions published in May 2026 ran an install script that sent the machine's hostname and working directory to a third-party endpoint. npm replaced it with a security placeholder in August 2026. In February 2026 a security firm described a trojanized clone of a real Oura Ring MCP server, backed by fake GitHub accounts and submitted to a directory, that installed an infostealer. The same month, a set of at least 19 typosquatted npm packages was found registering a rogue MCP server in the configs of Claude Code, Claude Desktop, Cursor and others.

Bugs in legitimate servers. The official Filesystem server's directory restriction could be bypassed (CVE-2025-53109 and CVE-2025-53110, fixed in 2025.7.1). The official Git server had three flaws (CVE-2025-68143, -68144 and -68145, fixed in 2025.12.18). The Figma server figma-developer-mcp had a shell-injection bug before 0.6.3 (CVE-2025-53967), and mcp-atlassian could be made to write arbitrary files before 0.17.0 (CVE-2026-27825). These weren't malicious. They were ordinary bugs in popular code, and a tool that takes a file path or a command argument is where they tend to live.

Local helpers and proxies. mcp-remote, a bridge that lets local clients reach remote servers, had a command-injection flaw in versions 0.0.5 through 0.1.15 (CVE-2025-6514, fixed in 0.1.16). The MCP Inspector, a developer tool, had no authentication between its browser page and a local proxy before version 0.14.1 (CVE-2025-49596). In October 2026 the Inspector project published a batch of nine more advisories.

Content that hijacks the agent. In May 2025 Invariant Labs showed that a public GitHub issue with hidden instructions could make an agent read private repositories and leak them into a public pull request. Their view was that the server code wasn't at fault and the real defence is limiting what the token can reach. In July 2025 General Analysis showed the same shape with Supabase: a support ticket containing instructions, an agent running SQL as service_role, and a private tokens table copied into the ticket. That was a demonstration on dummy data, and Supabase lists read-only and project-scoped modes among its mitigations. Neither case is a bug in the usual sense.

Config files that run code. Cursor fixed two bugs in 2025 where an approved MCP entry could be swapped without a new prompt (CVE-2025-54136, fixed in 1.3) and where an injected prompt could write a new server entry (CVE-2025-54135, fixed in 1.3.9).

Hosted platforms. A path-traversal bug in Smithery's build system exposed a platform token, reported privately in June 2025 and fixed within days, then written up in October. Asana's own hosted MCP server had a bug in June 2025 that could expose data across organizations. Asana took it offline and brought it back after a fix.

One caution on tool poisoning. Invariant Labs demonstrated in April 2025 that a tool description can hide instructions the model follows and the user doesn't see, and that a server can change a description after you approved it. We found no documented case of that exact trick being used against real victims. It is demonstrated, not observed, so we list it as a risk and not as a history.

The ten-point check

The ten checks, in order. Each one maps to an incident described above.

1. Copy the install command from the source, not a search result

Take it from the vendor's README or the registry entry, and check the exact package name and scope. @modelcontextprotocol/server-github and mcp-server-github are different packages with different owners. This is the first line of defense against postmark-mcp-style copies and typosquats.

2. Look at the package's age and publish history

A package a few days old with a dozen versions in two days deserves a closer look. postmark-mcp was two days old when its malicious version shipped. These commands work for npm without installing anything:

npm view <package> time --json
npm view <package> maintainers repository.url

The first shows when every version was published. The second shows who can publish it and which repository it claims. Check that the repository is the one the vendor's docs point to.

3. Compare the repository with its upstream

If a project says it's a fork or clone of something popular, open the original and compare. Look at the age of the accounts, who the contributors are, and whether the original author is missing from the list. The Oura clone had fake contributors added around a copied codebase. Stars, forks and contributor lists can all be faked, so use them as hints and nothing more.

4. Check the license and whether anyone is maintaining it

A license tells you what you may do with the code, and recent commits tell you whether bugs get fixed. Both are inputs to our trust score, which is described on the methodology page. They don't tell you the code is safe.

5. Search for advisories on the exact package and version

Version matters because the fix is usually a single release. Check the package's GitHub security tab, or query OSV, which aggregates advisories across ecosystems:

curl -s https://api.osv.dev/v1/query \
  -d '{"package":{"name":"<package>","ecosystem":"npm"}}'

For mcp-remote it returns the advisory for CVE-2025-6514. If your installed version is below the fixed one, update. For PyPI servers use "ecosystem":"PyPI".

6. Read the tool descriptions in full

Clients often show a short summary. A tool description can carry instructions meant for the model. If a description tells the assistant to read files, send data somewhere or keep quiet about something, that is a reason to stop. Read them again after an upgrade, because descriptions can change between versions. Our tools index and each server's tools tab show descriptions as published.

7. Give it the least access that works

Scope tokens to one repository and mark them read-only if you can. Use a read-only database role. Treat "allowed directories" on a file server as a feature to test, since the Filesystem server's own check was once bypassable. Several incidents above weren't server bugs at all, and a narrower token would have limited the damage in each.

8. Check how it listens

A local server should use stdio or listen on localhost only. The Figma server bound to all network interfaces, which made its bug reachable from the network. The Inspector could be reached from a web page. If a server opens a port, find out which address it binds to and whether it asks for authentication.

9. Don't combine the dangerous trio in one session

The risky setup is private data, plus text from outside you can't control (tickets, issues, emails, web pages), plus a way to send data out. The GitHub and Supabase demonstrations both had all three. You can often remove one: run the agent against a copy of the data, or turn off write access, or keep untrusted text out of the same session.

10. Pin the version, and treat MCP config files as code

Pin the version you reviewed instead of taking whatever is current at launch, and read the changes before you upgrade. postmark-mcp 1.0.16 was a one-line difference. If you clone a repository, its .mcp.json or .cursor/mcp.json can start a program on your machine, so read them before opening the project in an agent. To inspect a package without running it:

npm pack <package>

That downloads the tarball so you can read it. npm install --ignore-scripts skips install-time scripts, which is where the squatted mcp-server-github package did its work. It does nothing about code that runs when the server itself starts.

Remote servers

A remote server has a different risk. It can't read your disk, but it receives whatever you send it, and it can be updated at any moment by whoever runs it. Check who operates it, what scopes it asks for when you sign in, and what its terms say about your data. Hosted platforms that run servers for you also hold your credentials, which is what made the Smithery bug serious. The trade-offs are covered in remote vs local MCP servers.

What our trust score can and can't tell you

Each listing has a score from 0 to 100, built from a registry record, license, maintenance, popularity, documentation and some security basics. The security part is worth 10 points and checks only that the repository isn't archived, that there is an HTTPS remote or a package install, and that a package version is pinned.

So the score is a measure of evidence, and not an audit. It can't see the code, a changed tool description, a hijacked maintainer account or a malicious dependency. Of 47,703 listings, only 2,073 score 60 or more, largely because most listings have little public evidence to score at all. Our census has the breakdown. Use a high score as a reason to look first at a server, not as a reason to skip the checks above.

Other checklists

If you want a longer list, OWASP published a guide to securely using third-party MCP servers in late 2025, and its MCP Top 10 is in beta. The MCP specification has a security best-practices page aimed at people building clients and servers. Both go further than this post on logging, sandboxing and enterprise rollout.

Sources

Incidents, in the order mentioned.

• Koi Security on postmark-mcp, September 2025, with the npm registry record for the dates
• OSV record MAL-2026-5479, the mcp-server-github squat
• Straiker on the trojanized Oura MCP server, February 2026
• Socket on SANDWORM_MODE, February 2026
• Cymulate on the Filesystem server and its GitHub advisory
• Git server advisory
• Imperva on the Figma MCP server
• mcp-atlassian advisory
• JFrog on mcp-remote
• MCP Inspector advisory and Oligo's write-up
• Invariant Labs on tool poisoning and on GitHub MCP
• General Analysis on Supabase MCP and Supabase's response
• Cursor advisory, CVE-2025-54136 and CVE-2025-54135
• GitGuardian on Smithery
• Asana's incident page

Guidance.

• MCP security policy and trust model
• Official registry moderation policy
• MCP specification: security best practices
• OWASP: securely using third-party MCP servers and OWASP MCP Top 10