State of MCP server security, September 2026

Key findings

Most MCP servers are fine. The problem is concentrated in one place: remote servers that leave their tools open. A package runs on your machine with your permissions, so its code matters most. A remote server runs on someone else's, so who can call it matters most, and that is where the grades fall.

Grades

Every server is graded A to F on six public components: code, live reliability, tool poisoning, sign-in, maintenance and publisher identity (the rubric). Any critical finding is an F.

• AGrade A1,324 · 32%
• BGrade B1,751 · 42%
• CGrade C907 · 22%
• DD (hidden from default search)73 · 2%
• FF (blocked at the gateway)85 · 2%

Remote servers and sign-in

2,645 of the graded servers have a remote endpoint. We connected to each one the way any MCP client does, asked for its tool list, and never called a tool.

• Open, lists write tools1,250 · 47%
• Open, read-only tools447 · 17%
• API key in a header203 · 8%
• Other sign-in enforced131 · 5%
• OAuth549 · 21%
• Did not answer65 · 2%

"Write tools" means tools whose name or first sentence says they create, send, update, delete, post, pay, run or deploy something. An open endpoint that lists them lets anyone with the URL use the same tools your agent does. Some of these servers check a key inside each call, and some are public on purpose, like demos. The number describes what anyone can see from outside, not abuse we observed.

Only 21% use OAuth. Another 13% ask for an API key or another credential.

What's in the packages

For 1,487 servers we downloaded the published npm or PyPI package and read the code with pattern rules. We never ran it. 162 packages (11%) have at least one high-risk pattern.

• eval / new Function used142 · 10%
• Network call to a raw IP address88 · 6%
• Shell command built from a string (injection risk)74 · 5%
• Whole environment serialized (possible credential exfil)67 · 5%
• npm install lifecycle script present47 · 3%
• subprocess with shell=True37 · 2%
• curl | sh in a script32 · 2%
• Base64 decoded then executed9 · 0.6%
• Heavily hex-escaped string (obfuscation)6 · 0.4%

A pattern is a signal, not proof. eval inside a bundled library counts the same as eval in the server's own code, and a shell command built from a string is only dangerous when a tool argument reaches it. That is why every finding on a server's safety page shows its evidence.

Secrets and tool poisoning

Secrets. 10 servers publish what looks like a real credential in their package: private keys, OpenAI, GitHub, AWS or Google keys. A live key is a critical finding, so these grade F (or D for lower-risk keys) until the key is gone from the published version.

Tool poisoning. We checked the tool descriptions of 1,853 servers for instructions aimed at the model: override phrases, hidden instruction blocks, "don't tell the user", requests to read credential files or send data to an outside URL. 9 were flagged. Some of those are security tools that quote attacks in order to detect them, so read each flag with its evidence. Separately, 322 servers have a tool description over 2,000 characters, which is where hidden instructions tend to live.

Packages vs remote

Packages grade far better than remote-only servers, almost entirely because of sign-in.

By category

Categories with at least 40 graded servers. Each name links to the ranked list.

What to do

If you pick servers for a team

• Prefer remote servers with OAuth. With an open endpoint, assume anyone with the URL has the same tools you do.
• Read the safety page before you add a server. It lists every finding with its evidence: search any server.
• Keep write tools behind approval in your client, and pin package versions so a new release is a decision, not an update.

If you publish a server

• Put OAuth or at least an API key in front of any tool that changes something.
• Keep tool descriptions short and plain. Long descriptions look like hiding places.
• List your source repository. 900 servers don't, and nobody can check what they can't see.
• Find your listing, read your findings, and add the grade badge to your README. Fix something and it is rescanned on your next release.

Method and limits

• Source. Every server in the official MCP registry: 33,149 listings. 4,140 were graded when these numbers were taken. The scan queue takes the newest listings first, so this is the most recently published slice of the registry, not a random sample.
• When. The latest scan of each server, all run on 19 September 2026 with scanner 0.1.3.
• Remote endpoints. One initialize and one tools/list, as any client sends. No tool was called and nothing was written anywhere.
• Packages. Downloaded from npm or PyPI and read as text. Never installed, never run.
• Automated. Every number here comes from rules, not people. Rules have false positives, so each finding is published with its evidence and any grade can be appealed.
• Independent. No grade, ranking or badge on mcp.market is for sale.

Use this data

Quote any number on this page, with a link back to it. Suggested citation: mcp.market, "State of MCP server security, September 2026", mcp.market/research/state-of-mcp-security-september-2026.