Scope
Vetting third-party MCP servers before installation
The MCP ecosystem is enormous and mostly unmaintained. A 2025 measurement study of the ecosystem (arxiv.org/abs/2509.25292, 'A Measurement Study of Model Context Protocol') analyzed 8,401 valid projects — 8,060 servers and 341 clients — and found only 40.9% of sampled servers had been updated in the previous 90 days. Directory counts run far higher: one large-scale security crawl collected 67,057 servers across six public registries (arxiv.org/abs/2510.16558). So the realistic prior when you evaluate a random MCP server is: majority-stale, minimally reviewed, and installed with the same authority as your agent. The consequences are already documented. The postmark-mcp npm package shipped a backdoor in version 1.0.16 that BCC'd every email through the attacker's giftshop.club domain — with roughly 1,500 weekly downloads, it ran for about 8 days (Sept 17-25, 2025) before Koi Security caught it. And the tooling itself has had critical CVEs: CVE-2025-6514 in mcp-remote (CVSS 9.6, 437,000+ downloads exposed) let a malicious server achieve command execution on the connecting client. The verdict: an MCP server is a supply-chain dependency with live credentials, so it gets a vetting gate, not a copy-paste from a README. Note the honest caveat in section three — for well-known vendors, the official registry entry or Docker's curated MCP catalog does this diligence better than your manual review will.
Provenance and maintenance screening
4 checksVerify the publisher is who you think it is: official org account, linked from the vendor's own docs, exact package name
postmark-mcp was not Postmark's package — it impersonated one, and Postmark had to publish a disclaimer after the backdoor was found. Name-squatting works because MCP listings look interchangeable. If the vendor's own documentation doesn't link to this exact repository and package name, treat it as third-party code by an unknown author.
Check maintenance recency: last commit, open security issues, release cadence — reject or sandbox anything dormant for 6+ months
The arXiv 2509.25292 measurement study found only 40.9% of sampled MCP servers updated within 90 days. A stale server means unpatched dependencies, no one to receive a vulnerability report, and abandonment risk — and an abandoned popular package is a prime takeover target for exactly the postmark-mcp playbook.
Screen the server and its transport tooling against known CVEs before first run
CVE-2025-6514 (mcp-remote, CVSS 9.6, 437k+ downloads) allowed OS command injection from a malicious server's authorization_endpoint response; CVE-2025-49596 (MCP Inspector, CVSS 9.4) enabled RCE; even Anthropic's Filesystem MCP server had sandbox-escape flaws (CVE-2025-53109, a symlink bypass, CVSS 8.4, alongside directory-containment issue CVE-2025-53110 — Cymulate's 'EscapeRoute' disclosure). Five minutes on a CVE database against the package names in your MCP config is the cheapest control in this checklist.
Read the actual tool definitions and source for the handful of tools you will use — MCP servers are small
Most community servers are a few hundred lines wrapping an API. The postmark-mcp backdoor was one added line — a BCC field — visible to anyone reading the send-email handler. Unlike auditing a framework, auditing an MCP server is an achievable 20-minute task, and it also reveals scope creep like tools you never asked for.
Permission scope and blast radius
3 checksEnumerate what the server can reach: which credentials it receives, which APIs it calls, whether it can write or only read
An MCP server runs with whatever authority you hand it — the postmark-mcp lesson is that a compromised server exfiltrates through its legitimate channel (it just added a BCC). List every tool the server exposes and ask what the worst honest use of that credential is; that is your minimum blast radius.
Issue the server its own least-privilege, revocable credential — never your personal token or a shared admin key
A scoped API key with read-only access and a revocation path converts 'we shipped a backdoored server for 8 days' into 'we rotated one key.' A personal admin token in an MCP config converts it into a full account compromise. This single practice does more than any amount of code review.
Default untrusted servers to a sandbox: container without host filesystem access, egress limited to the API the server legitimately needs
The install/sandbox/reject gate needs a real middle option. A containerized MCP server with an egress allowlist can still do its job but cannot phone home to giftshop.club or read ~/.ssh — which is precisely what turns 'this server looks probably fine' into an acceptable risk.
Registry trust and ongoing hygiene
3 checksPrefer official-vendor or curated-registry listings over raw directory results — and accept that curation beats your manual review for big-name servers
Directory listings (a security crawl counted 67,057 servers across six public registries) are largely unvetted submissions. For servers from major vendors, the official MCP registry entry or a curated catalog like Docker's MCP catalog — where images are built and scanned — has stronger provenance guarantees than an individual engineer's spot-check. Spend your manual-review budget on the long-tail servers curation doesn't cover.
Pin versions and review diffs on update — an MCP server that was safe at install is not safe forever
The postmark-mcp backdoor arrived in version 1.0.16 of an already-installed, previously clean package. Auto-updating MCP servers re-runs the entire supply-chain bet on every release. Pin the version, and treat an update as a re-vetting event with a diff review, not a routine upgrade.
Inventory every installed MCP server org-wide, with an owner and a removal date for unused ones
MCP configs sprawl across IDEs, agents, and gateways with no central package.json to audit. When the next postmark-mcp advisory lands, the difference between a 10-minute response and a multi-day scramble is whether anyone can answer 'where is this server installed?' from an inventory instead of a grep across laptops.
Common Mistakes
- Copy-pasting an MCP config from a README with your personal admin token in the env block — granting an unreviewed package your full account authority on day one.
- Treating directory popularity as vetting, when the measured ecosystem baseline (arXiv 2509.25292) is that fewer than half of servers — 40.9% — saw an update in the last 90 days.
- Vetting once at install and auto-updating forever, the exact pattern the postmark-mcp v1.0.16 backdoor exploited against existing users.
- Screening only the server code and ignoring transport tooling, where the highest-impact CVEs actually landed (mcp-remote CVE-2025-6514, CVSS 9.6, 437k+ downloads).
- Hand-reviewing famous vendor servers while installing long-tail ones unreviewed — precisely backwards, since curated catalogs already cover the former and nobody covers the latter.